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Description 

BACKGROUND OF THE INVENTION 

This invention relates generally to Electronic Data 
Interchange ("EDI") systems and more particularly to a 
novel EDI translation system. 

EDI can be defined as the paperless, computer ap- 
plication to computer application, inter- and intra-organ- 
izational exchange ot business documents, such as pur- 
chase orders and invoices, in a structured, application- 
processableform. An EDI document can be sent directly 
to a business partner's computer over a communication 
line. EDI provides many benefits ; including: a) speed — 
documents are sent and received almost immediately; 
b) accuracy — documents are received as they were 
transmitted, eliminating manual rekeying of data and at- 
tendant errors; c) cost reduction — rapid document 
turnaround allows more accurate planning of inventory 
levels and reduces inventory reorder time; d) increased 
productivity — employees are freed from paperwork 
and available for other tasks; e) simplified broadcast 
communications to multiple trading partners (such as 
sending a request for proposal); f) directness of com- 
munication — data is routed directly from the person 
placing an order to the data processing system of the 
receiving organization; and g) data integration — data 
in documents can be integrated directly with existing 
business information and data processing systems. 

EDI involves three essential components: a) EDI 
standards; b) communications means; and c) an EDI 
translation system. EDI standards can be divided into 
formatting standards, dictionary standards, and com- 
munications enveloping standards. Formatting stand- 
ards govern: a) what documents can be communicated; 
b) what information is to be included; and c) how the 
information is to be sequenced and presented. 

Dictionary standards specify the meaning of the 
various elements being combined by the formatting 
standard. Communications enveloping standards de- 
fine how to group documents together into larger units. 
Communications enveloping saves on addressing by 
grouping a number of messages meant for the same 
destination from a specific source. The communications 
enveloping standard can also provide password securi- 
ty not present in paper forms of communication. Any of 
the standards can be proprietary standards (limited to 
one organization and its trading partners) or common 
EDI standards (adopted by industry-wide or cross-in- 
dustry users). 

EDI standard documents from and to which trading 
partner data is converted have detailed definitions in the 
pertinent EDI standard. EDI standards are maintained 
by various standards maintenance organizations. Ex- 
amples of such standards (and maintenance organiza- 
tions) are the ANSI X12 standard (developed by the 
American National Standards Institute's Accredited 
Standards Committee's X12 group), the UN-ED I FACT 



standard (Electronic Data Interchange for Administra- 
tion, Commerce, and Transport, an international stand- 
ard based on ANSI X1 2 and the Trade Data Interchange 
standards used in Europe), the Uniform Communica- 
5 tions Standards ("UCS"), and TDCC (developed by the 
Transportation Data Coordinating Committee). The 
standards are not invariant — they continue to evolve 
to meet the changing needs of information transfer. 

Standards may have different terminology. There 
are however, similarities in the meaning associated with 
the terms. Whether termed a transaction set (ANSI 
X12), a standard message (EDI FACT), or a document 
(UCS) : there is an electronic representation of a paper 
business document. A unique identifier code is assigned 
in the standard for each type of business document. As 
an example, in the ANSI X12 standard an invoice is re- 
ferred to as X12 document number X12.2, with a trans- 
action set identification code of 810. 

EDI standards are developed using a set of abstrac- 
tions: a) there is a unit of data called a data element; b) 
data elements can be grouped into compound data el- 
ements; c) data elements and/or compound data ele- 
ments are grouped into data segments; d) data seg- 
ments can be grouped into loops; and e) loops and/or 
data segments are grouped into a business document. 

The abstraction is based on an analogy to a paper 
document. Paper documents can be considered to have 
three distinct areas: the heading area, the detail area, 
and the summary area. In many cases the detail area 
consists of repeating groups of data elements. For ex- 
ample, in an invoice, the elements are the items being 
invoiced and are usually printed as lines in a columnar 
list. In the terminology used in the standards, these re- 
peating groups are loops. Grouping data elements into 
loops proves unwieldy because of the number of data 
elements that must be considered. The standards there- 
fore group data elements into data segments and com- 
pound data elements. 

Transaction set standards specify whether data 
segments are mandatory, optional, or conditional and 
indicate whether, how many times, and in what order a 
particular data segment can be repeated. The transac- 
tion set standard does not specify the content of individ- 
ual data segments. Instead, a segment directory identi- 
fies the specific data elements to be included in each 
data segment. The segment directory is composed of a 
series of data segment diagrams, each of which identi- 
fies the data elements to be included in a data segment, 
the sequence of the elements, whether each element is 
mandatory, optional, or conditional, and the form of each 
element in terms of the number of characters and wheth- 
er the characters are numeric or alphabetic. 

Data segment diagrams include the following com- 
ponents. The data segment identifier identifies the da- 
ta segment being specified. The data element separa- 
tor is a user-selected character that precedes each con- 
stituent data element and serves as a position marker. 
The data segment terminator is a user-selected Char- 
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acter used to signify the end of the data element. Ele- 
ment diagrams describe individual data elements. 

Depending on the standard, element diagrams can 
define an element's name, a reference designator a da- 
ta dictionary reference number specifying the location 
in a data dictionary where information on the data ele- 
ment can be found, a requirement designator (either 
mandatory, optional, or conditional), a type (such as nu- 
meric, decimal, or alphanumeric), and a length (mini- 
mum and maximum number of characters). A data ele- 
ment dictionary gives the content and meaning for each 
data element. 

EDI standard documents are electronically pack- 
aged or "enveloped" for transmittal between trading 
partners. Enveloping can be at several levels. The first, 
or innermost, level of enveloping separates one docu- 
ment from another. This is accomplished by attaching 
transaction set headers and transaction set trailers to 
each transaction set, or document. At a second level of 
enveloping, documents can be packaged together into 
groups known as functional groups. An example of a 
functional group is a purchase order and an invoice, 
which are often sent together in both the paper and EDI 
worlds. Each functional group is packaged with a func- 
tional group header at its beginning and a functional 
group trailer at its end. This second level of enveloping 
is an optional level in most standards. 

At a third level of enveloping, all functional groups 
to be sent to a single trading partner can be packaged 
together. This enveloping consists of an interchange 
control header and an interchange control trailer bound- 
ing either the packaged functional groups and/or the 
document. 

The second component of EDI is communications 
means. EDI standard documents are transmitted elec- 
tronically between trading partners' computers. The 
transmittal can be directly between trading partners, via 
a direct private network in which the computers are 
linked directly. Direct networks become difficult to main- 
tain with larger numbers of trading partners. The alter- 
native is to use a third-party, or value-added network 
(VAN). A VAN maintains an electronic mailbox for each 
trading partner that can be accessed by each other part- 
ner (with appropriate security restrictions). 

The standard does not specify a communications 
standard except to the extent to which it describes the 
enveloping standard and the way in which transmis- 
sions can be acknowledged. There are de-facto stand- 
ards such as IBM 2780/3780 BSC protocols used as file 
transfer protocols. Virtually every EDI VAN supports 
these protocols because of their pervasive use. 

The third component of EDI is the EDI translation 
system, which performs at least the functions of data 
communication and document translation. Document 
translation is the most significant function in this com- 
ponent, and is implemented through an EDI translation 
software. 

In practice, participants in EDI select and agree to 



use a proper subset of the document standard. Such 
agreements among trading partners are too numerous 
to be included in an EDI translation software. The EDI 
translation therefore needs to provide a way for the user 

5 to express how to process or generate the EDI docu- 
ment in compliance with the agreement. 

One example of the need for compliance with a trad- 
ing partner agreement is when one trading partner is to 
automatically post an EDI document to a processing 

10 system. A purchase order received from a customer 
could be booked automatically through the recipient's 
order entry system. Since the agreement and the inter- 
face requirements to the order entry system are not de- 
fined in the EDI translation software, the user of the EDI 

15 translation software must specify how to perform the 
translation. 

The EDI translation software must provide three 
functions in conjunction with giving the user a means of 
expression for performing the translation. First, the soft- 

20 ware must provide mechanisms to navigate and manip- 
ulate EDI documents. Second, the software must be 
able to produce the records that are to be interfaced with 
the order entry system. Third, the system must provide 
the user with means to express (using these primitives) 

25 a complete procedure for transforming an EDI docu- 
ment into something that is compatible with the user's 
interfacing requirements. 

In some cases a user may find it advantageous to 
automatically print an EDI document on paper in a tor- 
so mat that is familiar to the user. For example, it may be 
helpful to print an invoice because the accounts payable 
system is implemented manually. As in the discussion 
above, the translation software does not include a defi- 
nition of the format in which the user expects the output. 

35 The user must therefore specify this information. 

The development of prior EDI formatting or transla- 
tion software can be traced through three generations 
— translation software of the invention represents the 
fourth generation. The first generation of software was 

40 developed in the late 1 970s and early 1 980s to support 
a variety of private formats. The private formats were 
developed by large corporations to allow them to ex- 
change business documents with their trading partners. 
The formats did not conform to any industry standards. 

45 The software used in these systems resembled subsys- 
tems of existing general business applications. 

These first generation systems typically involved 
the exchange of private-format data files and associated 
data processing programs. Trading partners typically 

50 communicated directly with each other over private net- 
works. Examples of first generation systems include 
General Motors' and Ford's automotive "release" sys- 
tems and retail industry order processing systems, such 
as those used by Sears, J.C. Penney, and K Mart. 

55 The document FR-A-2 371 098 discloses a system 
for transmitting numeric data, employing a commutation 
of messages in terms of packages. A sort of de-envel- 
opping procedure (in view of communication of data with 
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different format) is present in the operation of this sys- 
tem. The document teaches that there is an increasing 
need for transmitter-receivers intheterminals of existing 
communication networks requiring commutation of nu- 
meric data. It is essential that the terminals have the ca- 
pability to communicate with each other despite the di- 
versities of codes, modulation techniques and proto- 
cols. The document also teaches that communication 
processors have been employed in the past for the con- 
version of codes and other data. The known system is 
able to convert the data received from various sources 
into a format having a protocol adapted to the system. 
In particular, the known system may perform facsimile 
transmissions having a commutation of packages and 
having a protocol which is adapted to the ensemble of 
the system. 

The second generation was characterized by the in- 
troduction of variable length, hierarchical document 
standards such as TDCC (used in the transportation in- 
dustry) and UCS (used in the grocery industry), which 
created a need for a more generalized approach to 
translating those standards into computer-processable 
business forms. 

Translators of this generation typically employed 
fixed data files transferred to an intermediate process 
that translated the document into a form usable by host 
applications. The translator's primary task was to con- 
vert the records in the data files from variable length for- 
mat to a fixed length format that could be processed by 
traditional batch applications. These translators were 
known colloquially as "asterisk strippers" because they 
had no capability to manipulate data between records 
or to change the placement of data within records. 

A major shortcoming of these second generation 
translators was that a large amount of additional inter- 
mediate processing was required, typically involving 
programming tasks to integrate the EDI document into 
an application system. Networks and major trading part- 
ners tended to overlook this problem in their efforts to 
expand trading partner relationships. The dissatisfac- 
tion of end users with the high software maintenance 
demands of this post-translation processing require- 
ment led to the development of the third generation of 
software. 

The document Communications of the ACM ; Vol. 
30, No. 5, May 1987, New York, US, S.A. Mamraketal.: 
"A software architecture for supporting the exchange of 
electronic manuscripts", pp. 408 -41 4 discloses an elec- 
tronic manuscript exchange tackling the known prob- 
lems in translating among the wide variety of electronic 
representations. The system supports both the use and 
the creation of translation tools. 

The third, or current, generation of translation soft- 
ware attempts to provide higher levels of transform ca- 
pability so that an EDI document can be put into a form 
closer to the input required by the user's integrated ap- 
plication software. These translators provide for table- 
driven systems and "dynamic mapping." 



The translation software uses a table structure to 
perform the translation. The tables consist of the stand- 
ard data dictionary and syntax rules for the data seg- 
ments and elements of a given EDI transaction set. The 
5 software selects the appropriate table to perform the 
translation for a specified EDI transaction set to be gen- 
erated. 

Dynamic mapping allows the user to identify the re- 
lationship of elements within a segment to fields in an 

10 application input document and vice versa. Instead of 
fixing record lengths, the systems allow the user to put 
data elements into different data files in any location. 
Rather than being limited to a single fixed length file in 
a transaction set, the user can select data from multiple 

15 files, in any order within the file, and present the data to 
the translator. 

The ACS Network Systems EDI 4XX product, avail- 
able from ACS Network Systems of Concord, California, 
is typical of third generation software products. The data 

20 communication component of ACS 4XX provides the 
means to generate and maintain a communication line 
directly with a trading partner or to a third party data net- 
work and the means to control the process of sending 
and receiving documents to and from trading partners. 

25 The translation component of ACS 4XX translates in- 
coming standard business documents from an EDI 
Standard format to a format usable by applications pro- 
grams and reverses the process for outgoing data. 
These third generation systems suffer from several 

30 problems. First, the dynamic links between fields in ap- 
plication databases and data elements in EDI docu- 
ments are unconditional — the field mapping or linking 
is construed to be constant in any given application. The 
systems are therefore unable to represent the condition- 
's al expressions that appear as "notes" in almost all stand- 
ards. For example, a segment definition may have a 
conditional note that specifies that either the second da- 
ta element must be present or both the third and fourth 
elements must be present. Although some translators 

40 have attempted to comply with these notes through the 
actual translator software code, this technique has prov- 
en inadequate and difficult to maintain as standards and 
documents evolve. Further, the standards definitions 
employed by these systems have relied on a data base 

45 schema of the standards definition This is a relatively 
inflexible approach that does not readily accomodate 
the continual evolution of the standards. 

Second, these systems assume that EDI input will 
require non-EDI, or application, output. This prevents 

50 the systems from acting as true translators, capable of 
communicating any type of input and any type of output. 
Similarly the communication components of such sys- 
tems assume that their only interfaces would be with 
EDI-capable networks. This precludes straight file trans- 

55 fer capability between computers, and prevents the sys- 
tems from acting in a terminal emulation mode to inter- 
face with other computers. Further, the communications 
interface does not provide the structure for unattended 
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operation; the systems cannot act as passive commu- 
nications systems for receiving calls from outside sys- 
tems. There is also no method for allowing an outside 
application to send the system data for translation into 
EDI format. 

Third, there can be structure or sequence clash be- 
tween the EDI document and the application transac- 
tion's structure requirement. The previous generation 
systems provide a tool for specifying transformation of 
data through the use of a mapping program. The map- 
ping program includes assumptions about the corre- 
spondence of structure and sequence between source 
data and target data. The tool therefore cannot be used 
to translate data with a structure or sequence clash be- 
tween the source data and target data. 

EDI documents are defined using a specification 
that prescribes a sequence and structure to the docu- 
ment. When the application transaction's structure and 
sequence differs from the corresponding EDI document 
specification, the user is required to develop a set of pro- 
grams that deal with the structural or sequence differ- 
ence to achieve a seamless interface to the application. 

For example, a retail store may send to a manufac- 
turer purchase orders with store distribution specifica- 
tions attributed to each line item. If the manufacturer re- 
quires separate paperwork for each shipping location, 
the grouping of data as expressed by the EDI document 
clashes with the manufacturer interface requirement. 
The clash is caused by the different structure assumed 
when producing the EDI document (which specifies how 
to distribute the order for a specific item to multiple ship- 
ping locations) and the structure assumed by the order 
entry system (which assumes that an order document 
contains items for a specific shipping location). 

Third generation systems do not attempt to address 
this problem. The general approach is to produce a file 
that contains the necessary data in a rigid, hierarchical 
structure and to force the user to develop a set of pro- 
grams using whatever programming language and util- 
ities are available to change the structure. Some of 
these programs can become very complicated. 

Fourth, third generation translators generally have 
limited pattern matching capability. This reduces the 
scope of acceptable types of input. The pattern match- 
ing of application transaction files is very limited. 
Records are identified using a strictly specified value in 
a specific position in the record. Therefore, unless the 
application transaction file created from the computer 
application contains these very specific value(s) (Le, 
H01, H02, D01, D02, etc.), an interface program must 
be developed to supply data to the translator. 

Fifth, the current systems have strict one-to-one 
correspondence between source and target docu- 
ments. The systems therefore cannot receive a docu- 
ment, such as a shipping notice, and generate multiple 
transactions, such as a receiving notice, an inspection 
notice, and an invoice notice. 

Sixth, prior systems have limited capacity for eval- 



uating performance errors. For example, a user who 
creates a mapping specification with a table driven or 
dynamic mapping scheme may find during operation 
that some of the data elements are output incorrectly — 
5 the value of a data element for one document may turn 
up in another document. It can be difficult for the user 
to find the source of the error because the systems pro- 
vide no debugging mechanism for finding the problem. 
While a debugger capability could theoretically be add- 
10 ed, it would be onerous to implement because the struc- 
ture of the systems (being non-language based) is not 
susceptible to a debugging facility. 

Finally, the third generation translators limit opera- 
tions to simple assignment semantics. There is no pro- 
's vision for performing arithmetic operations on source 
data elements to produce a target data element. Per- 
forming logical operations or string manipulation are 
usually not provided. 

20 SUMMARY OF THE INVENTION 

The invention, as claimed, overcomes the problems 
with the prior generation systems with an EDI translation 
method that receives data from a source in one format, 
25 executes a script to translate the data into a second for- 
mat, and transmits the data in another format to a des- 
tination. The system has the ability to transform input 
data from, and into, virtually any format and to produce 
more than one output for each input document. The sys- 
30 tern employs a tree data structure and a script of trans- 
lation instructions to overcome the hierarchical data 
structure limitations imposed by the prior generation 
systems. 

The system can pattern-recognize records that are 
35 not explicitly differentiated. It provides flexibility in using 
virtually any communication system to communicate 
EDI as well as non-EDI documents. The system em- 
ploys a model that assumes that both input and output 
are to be communicated and is therefore not con- 
40 strained to use with a particular processor but can in- 
stead act as a true communication front end. 

The system addresses the difficulty that prior sys- 
tems had in expressing syntax notes associated with 
segments in relational terms. This is done by expressing 
45 the notes using language construction of logical opera- 
tors on data elements. For example, the semantic ex- 
pression "(-or 2 (-and 3 4))" means "either the second 
element or both the third and fourth elements must be 
present." 

50 The system addresses the inability of prior systems 
to handle structure clash between an EDI document and 
an application's data structure requirement by providing 
data and control structures. The control structures in- 
clude such basic structures as executing a series of 
55 commands while some predicate condition exists. 

The system supports data structures such as multi- 
dimensional arrays and an EDI tree data structure. The 
EDI tree data structure represents an instance of an EDI 
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document. The tree provides random access operation 
on the document allowing the user to specify the se- 
quence in which access to the EDI document is to be 
made. The system further provides a set of access prim- 
itives. These two tools allow the user, for example, to 
read a document and process it repeatedly once for 
each of several shipping locations. 

The system facilitates support for relational level 
notation in EDI document definitions that specify hierar- 
chical nesting, such as EDI FACT standard documents. 
It supports implicit as well as explicit notation in EDI doc- 
ument definitions. The tree access notation enables the 
EDI programmer to reference EDI data elements so that 
a language can support it as one of its datatypes. With- 
out such a notation, support for EDI in a programming 
language would be difficult. Nesting and repetition of 
segments is discussed in ISO Publication 9735, pp. 6-9 
(1988). 

The system also overcomes the limited ability of pri- 
or systems to pattern match data by providing a pattern 
matching capability that can read a fairly large set of pat- 
terns that follow an LL(1 ) grammar (for a description of 
LL(1) grammar see Aho, Sethi, & Ullman; Compilers: 
Principle, Techniques and Tools, pp. § 4.4 (Addison 
Westley 1986). The user can formulate a filemap defi- 
nition and record definitions to express the expected 
pattern. The system also allows the user to generate as 
many target documents as required from a single source 
document. 

The system also overcomes the failure of the prior 
systems to provide a debugging capability. Since the 
system is language based, a conventional debugging 
facility can be readily provided. 

Finally the system has a broader range of opera- 
tions performed than the prior systems and provides ex- 
pressions such as those involving logical and arithmetic 
operators and string manipulation. Data transformation 
is enabled by use of an assignment statement. The as- 
signment statement accepts an expression on the right 
hand side as in: 

a = b + c 

This statement specifies that a is computed from b 
plus c. The elements a, b, and c could be elements from 
the source or target, although a is likely to be an element 
of the target and b and c are likely to be elements of the 
source. In this example, a "+" operation is used in the 
right hand side expression. The system supports many 
such operations including "substring" to extract a portion 
of a string. These operations are termed language 
"primitives". The set of language primitives depends on 
the nature of the problem. However, by employing a pro- 
gramming language implementation, the invention al- 
lows a user to combine these basic operations into com- 
plex expressions. This expressiveness allows the user 
to specify more complex transformations. 



The system is organized into four component work 
centers: 

a) Communications Interface (having a communication 
session as its input work unit); b) De-enveloping (having 
5 an interchange as its input work unit); c) Translation 
(having a document as its input work unit); and d) En- 
veloping (having an enveloping request as its input work 
unit). 

The communications interface work center uses a 
script to schedule a communication session and de- 
scribe how to break up the contents of the communica- 
tion into units of de-enveloping work. 

The de-enveloping work center divides a communi- 
cation interchange into its component documents. It al- 
so performs a routing function, routing documents to the 
required destination. 

The translation work center manipulates an incom- 
ing document into the format that is expected by another 
system. It can convert EDI data to a format that can be 
printed or used by application programs and can convert 
a file created by an application program to a standard 
EDI format. It is implemented as an interpreter or com- 
piler that understands translation primitives and can be 
used with a script to perform transformations on many 
kinds of data. In the illustrated embodiment, each of 
these work centers are implemented using a novel EDI 
programming language, referred to herein as the e-lan- 
guage. 

BRIEF DESCRIPTION OF THE DRAWINGS 

FIG. 1 is a block diagram of data flow through the 
EDI translation system. 

FIG. 2 is a block diagram of a hardware implemen- 
tation of the invention. 

FIG. 3 is a sample communication script. 
FIG. 4 is a sample EDI de-enveloping script. 
FIGS. 5A to 5F are a sample application de-envel- 
oping script. 

FIG. 6 is a graphic representation of the organiza- 
tional structure in which files are stored before envelop- 
ing. 

FIG. 7 shows sample application data input for a 
translation operation. 

FIG. 8 shows sample EDI output corresponding to 
the input of FIG. 7 as produced by the script shown in 
FIG. 13. 

FIG. 9 is a document definition for an X12 810 in- 
voice implemented in the e-language. 

FIG. 10 shows two sample segment definitions im- 
plemented in the e-language. 

FIG. 11 shows two sample element definitions im- 
plemented in the e-language. 

FIGS. 1 2A to 1 2C show three sample data type def- 
initions implemented in the e-language. 

FIGS. 1 3A to 1 3F show a sample translation script 
for translating an application document to an EDI docu- 
ment. 
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FIGS. 14A to 14F show a sample translation script 
for translating an EDI document to an application docu- 
ment. 

DETAILED DESCRIPTION 

The system is organized into four component work 
centers: a) Communications Interface; b) De-envelop- 
ing; c) Translation; and d) Enveloping. The flow of data 
through the system is illustrated in FIG. 1. Data flows 
into the system through communications interface 1. It 
then flows to the de-enveloper 2, to the translator 3, and 
to the enveloper 4. From the enveloper, the data flows 
back to the communications interface and thence out of 
the system. 

In the illustrated embodiment, a data item flowing 
through the system can be considered conceptually as 
a package with a packing slip. As the data item is proc- 
essed by each component of the system, some informa- 
tion is read from the packing slip, and additional infor- 
mation is written to the slip. The information that appears 
on the slip determines how the package will be proc- 
essed. The system uses a "routing form" as an abstract 
representation of the packing slip. A routing form follows 
a data item through the system, and a component can 
both read from and write to the routing form. The behav- 
ior of a component may depend upon information that 
is read from the routing form. 

The routing form provides for the following informa- 
tion: a) interchange sender; b) interchange receiver; c) 
functional group sender; d) functional group receiver; e) 
node (the network or application used); f) facility (the 
communication protocol); g) content type (EDI, applica- 
tion, or text); h) document type (transaction set identifi- 
er); i) translation script: j) functional group; k) error mes- 
sage; and I) functional acknowledgement flag. The in- 
formation is placed in the routing form in the following 
order: a) in the communications interface - the node, fa- 
cility, and content type; and b) in the de-enveloper - doc- 
ument type, senders, receivers, functional group, func- 
tional acknowledgement flag, and translation script. Er- 
ror messages are written to the routing form by which- 
ever module detects the error. 

The EDI translation system can operate on a variety 
of hardware. In the illustrated embodiment, the system 
operates on a microcomputer having a 20 MHz Intel 
80386 processor, 4-8 MB of RAM, one or more serial 
ports, a 100 MB fixed disk drive, a 2400 Baud modem 
with V.22 VIS/MSP protocol, and having a UNIX oper- 
ating system. The system may also be operated on a 
local area network, with different machines implement- 
ing different functions of the system. For example, one 
machine can serve as the communications interface 
while another provides file storage. 

As shown in FIG. 2, the system operates on micro- 
computer 10, which is connected to one or more EDI 
networks 20 and a host 30. The connection 40 between 
the system and the host is a synchronous connection 



such as a Bell 208A modem or another line driver. EDI 
data is transmitted to and from trading partners via the 
EDI networks, while application data is transmitted to 
and from applications operating on the host. All data 

s transmission between the system and either the host or 
the EDI networks is routed through the communications 
interface work center, shown at 50. 

In an alternate embodiment, the host on which the 
applications are operated and the microcomputer on 

10 which the EDI system operates are combined, so that 
applications are operated on the same machine as the 
system. 

In the illustrated embodiment, each of the EDI sys- 
tem work centers is implemented in the e-language. Of 

15 course, the work centers could be implemented in other 
languages, such as Lisp or C+ +, although with greater 
difficulty. The e-language uses arithmetic, boolean, 
functional, and control structures similar to those in BA- 
SIC, Pascal, and COBOL. In addition, the e-language 

20 contains functions and data structures unique to EDI 
processing. These specialized functions include facili- 
ties for converting an EDI document to an EDI data tree 
and for performing the reverse operation. The e-lan- 
guage also contains commands to determine the status 

25 of various parts of the EDI system, and to perform low- 
level operations on these parts. These functions, and 
other aspects of the e-language, are described in the 
"e" Programmer's Reference Manual, attached as an 
Appendix hereto and being a part of the disclosure of 

30 this application. 

The e-language allows the user to perform pattern- 
matching operations. For example, the e-language can 
be used to describe the format of an application file and 
to select the portions of the file to be used. This allows 

35 the production of a customized EDI document from an 
application file. 

The e-language is structured in the manner de- 
scribed in the attached Appendix. The syntax of the e- 
language borrows some of the command names and 

40 clauses from BASIC and COBOL and general syntax 
structures from Pascal. 

The system employs the concept of a data stream. 
A stream is a source of input or a destination of output. 
An input/output function generally takes a stream as one 

45 of its arguments. When a program is executed, a default 
input stream and a default output stream are created. 
Stream objects are bound to one or the other stream. 
Other streams can be opened during a program execu- 
tion that can be bound to variables used in other run- 

50 time calls for input/output purposes. 

Communications Interface 

The communications interface has two parts: a) a 
55 scheduler: and b) a set of facilities drivers. The sched- 
uler is a program that references a usercreated table to 
determine when to communicate with sources of infor- 
mation (such as a trading partner or an application). The 
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actual communication is done through a facility driver. 
All of the mechanics of transferring files via a given com- 
munication protocol are packaged in the facility driver, 
and are accessible to the user through a communication 
script. The script, which can be written in the e-lan- 
guage, specifies the procedures to be used to create a 
de-enveloping work unit. 

The communications interface work center defines 
the concept of a logical connection to the outside world 
as a node. The logical implementation of the connection 
is a communications facility. Two kinds of nodes are de- 
fined: a) an EDI connection (or EDI network); and a non- 
EDI connection (or application). Thus, in FIG. 2, EDI net- 
work 20 and an application running on host 30 are each 
nodes. The node name is used to symbolize the network 
or application, binding the name to the specific commu- 
nication facility that is used to execute the communica- 
tion. In the illustrated embodiment, the system assumes 
that communication facilities exist in the form of hard- 
ware and software. These facilities are not part of the 
system; the system interfaces to the facilities through 
facility drivers, which are part of the system. The inter- 
face consists of a driver and a script. A driver is a pro- 
gram capable of communicating with the specific com- 
munication facility. This driver supports a set of primi- 
tives that is supported by the e-language. Communica- 
tions packages usually have either a programming in- 
terface or a user interface. The driver must be interfaced 
to whichever interface the specific communication pack- 
age has. A script is a program capable of configuring 
the communication package. This gives the system the 
ability to set up and use the proper script. 

The different facilities to which the system could in- 
terface are numerous. It is therefore economical to have 
interfaces for common facilities such as Unix Mail, Unix 
File System, and Remote Job Entry. The operations pro- 
vided by the interface depend on the capabilities of the 
facility, but as a minimum include send and receive prim- 
itives. 

A facility client is capable of both sending and re- 
ceiving files. The EDI translation system can be con- 
nected to a network node using a Binary Synchronous 
Remote Job Entry facility. The facility may be imple- 
mented by software such as the AT&T Synchronous 
Gateway. The gateway uses an account name to man- 
age communication. When establishing communication 
with the network node in conjunction with the gateway, 
the network node is mapped to an account name, thus 
integrating the gateway communication software with 
the EDI system. A similar correspondence can be es- 
tablished between an application node and the gateway 
account. Other facility clients can include Unix Mail, X- 
MODEM, and the file system in the operating system. 

Each node can also be assigned a schedule spec- 
ifying the times when activity with the node is expected 
to occur. The schedules are derived from configuration 
specifications that users provide. The configuration 
specifications are configuration texts, rather than e-lan- 



guage scripts. Each schedule specifies the time and an 
associated script that is expected to be executed. The 
script, which, in the illustrated embodiment, is imple- 
mented in the e-language, contains details of how the 
5 communication is to be performed. A sample communi- 
cation script for a Unix Mail interface is shown in FIG. 3. 
The script embodies four primitives. The first, shown at 
8110, is Envelope, which request that envelopes be 
made for data that is ready to be transmitted through the 
10 Unix Mail. The ATTM AIL parameter, 8120, identifies the 
network. The enveloped data is returned as a data 
stream. The second primitive is SendUnixMail. shown 
at 8210, which sends the enveloped mail messages in 
the stream out through the Unix Mail facility. Next, Rea- 
15 dUnixMail shown at 8310, picks up from ATTMAILany 
mail message, and develops a list of mail messages. 
Finally, MakeMail Interchange, shown at 8410, con- 
verts a mail message into an interchange. 

This example illustrates the use of interface primi- 
20 tives that were developed as part of a Unix Mail driver. 
The example uses the Unix Mail facility to send and re- 
ceive messages through the ATTMAIL network. If the 
pertinent parameter (such as 8120) were changed, the 
script could equally well use any other network. Scripts 
25 for simply reading mail without sending mail, or sending 
mail without reading mail could also be developed and 
scheduled to execute at different times. 

The scheduler is driven by a scheduler table, in 
which the rows are nodes and columns are facilities. 
30 Each cell in the table can contain a schedule instruction. 
The schedule instruction can specify that a communica- 
tion should occur at a fixed interval or at a fixed time. 

A facility is an interface with specific communication 
resources provided in the host machine. The facility in- 
35 eludes information about how to use the communication 
resource. Because each facility is programmable, and 
therefore variable, a command must be issued to spec- 
ify the communication script that the facility client should 
execute. The script is specified in the scheduler table. 
40 Data received from a communication session is 
sent to the de-enveloper as a unit of work. The unit of 
work is assigned a script name, which identifies the de- 
enveloping procedure that will be used to divide the con- 
tents of the communication session. 
45 The system also provides the structure for unat- 
tended operation, acting as a passive communications 
system for outside systems to call and to send it data 
for translation into EDI. The structure, based on the driv- 
er and configuration described above, allows the system 
50 to take advantage of existing communications packag- 
es. One of the standard facilities provided with the sys- 
tem is a file system communication facility. The facility 
consists of a listener that polls specified directories for 
files and a depositor that places enveloped data into a 
55 target file or separate files into a target directory. Files 
with specific names or files found in a specific directory 
are picked up by the system. The file name or the source 
directory determines the type of data and the require- 



25 



30 



35 



40 



45 



50 



8 



15 



EP 0 553 098 B1 



16 



merits for de-enveloping. 

The user can therefore use the file system commu- 
nications facility in conjunction with any communication 
system that places incoming data into a specific direc- 
tory to simulate incoming support. The user can also de- 
velop a program to transmit data deposited in a partic- 
ular directory or file to the communication program. 

These capabilities provide the tools for running un- 
attended for communications initiated by another party. 
The system provides a scheduling mechanism for each 
network interface and application interface to allow the 
automatic scheduling of communications initiated by the 
system. The scheduling is done using a facility like timer 
services provided by some operating systems, such as 
the "cron" facility of the Unix operating system, which 
provides for the execution of specified commands ac- 
cording to a time schedule. 

De-Enveloping Work Center 

When incoming data contains multiple documents 
in one unit of work, the de-enveloping work center of the 
EDI system must break the work into single documents. 
The de-enveloper has three purposes: a) to strip off the 
enveloping layer and divide a communication inter- 
change into its component documents; b) to identify the 
sender, receiver and transaction type; and c) based on 
that information, determine the type of transformation 
needed and the destination of the transformed docu- 
ment, saving the enveloping information as attributes of 
each document. The process is script driven. The con- 
tent type and the de-enveloper script are determined by 
the communications process; the identity of the inter- 
face is known at the time the communications process 
located the data. If the data was located by a network 
interface, the content type is EDI and the EDI de-en- 
veloper script is invoked for that network interface. If da- 
ta from an application interface was located, the content 
type is application transaction and the application trans- 
action de-enveloper script is invoked. 

Script selection is performed through a table, the 
table having nodes as rows and the type of data as col- 
umns (being either EDI data, applications data, or text). 
In the case of EDI data ; the de-enveloper work unit (an 
interchange) is de-enveloped into its component func- 
tional groups and then into transaction sets. Each indi- 
vidual transaction set is then considered a separate 
translation work unit. In the case of an application file, 
the report is divided into individual invoices. Each indi- 
vidual invoice is then considered a separate translation 
work unit. The system has the capability to handle text 
files, but performs no de-enveloping, translation, or en- 
veloping on them. 

The de-enveloping process is also script driven. Dif- 
ferent scripts, and methods, are used depending on 
whether the data is EDI or non-EDI. The system gives 
the user the capability of defining each script to meet 
the user's particular requirements. 



For an EDI input, the de-enveloping script uses the 
following general procedure. First, the start of the file is 
marked. Then, for each found interchange, the following 
steps are taken. First, data from the last mark to a po- 
5 sition just prior to the interchange envelope is returned 
as a de-enveloper unit of work, considered an applica- 
tion transaction with the same name as the network in- 
terface. Second, the interchange envelope is read and 
an attribute list consisting of interchange values is pop- 
10 ulated. Third, for each functional group envelope found 
within the interchange envelope, the following steps are 
taken. First, the functional envelope is read and addi- 
tional attributes are populated. Second, for each docu- 
ment envelope found within the functional group enve- 
15 bpe, the following steps are taken. First, the document 
envelope is read and document attributes are populat- 
ed. Second, a mark is set. Third, a translation unit of 
work is created using data from the mark to the end of 
the document. Fourth, additional document attributes 
20 are populated from the end of the document. When no 
additional documents envelopes are found, additional 
functional group attributes are populated from the end 
of the functional group. When no additional functional 
groups are found, a mark is set. The entire process 
25 above is repeated until no more interchange envelopes 
are found. 

A sample de-enveloping script for EDI data is 
shown in FIG. 4. The primitive Openlnterchange, shown 
at 9120, specifies the types of interchange envelopes 
30 expected to be present in the data (ISA interchange en- 
velope types in the example). The variable "cursor," 
shown at 9110, is used to point to the current position 
in the input/output stream. The primitive "Deenvelope," 
shown at 9210, extracts a document from a found en- 
35 velope. The example script extracts documents from all 
envelopes that it finds. 

The de-enveloper reads just enough of the inter- 
change file to extract a transaction and then sends the 
data obtained to another work center for further routing 
40 through the system. In general, data is passed from one 
work center to another using queues. A configuration 
file is used by all the work centers to determine what 
work centers are available to the system. 

The de-enveloper tracks the interchange and func- 
45 tional group information as it processes the interchange. 
Users can access the information through the element 
reference notation, as described below. 

In the case of an application transaction, the de-en- 
veloping process is different. The user must specify how 
50 the data is to be divided into individual transactions be- 
cause the patterns that specify the boundaries between 
documents are not known. The user employs the pattern 
matching capability of a function termed SPLIT to split 
off the individual transactions. The pattern matcher is 
55 implemented in the e-language using a technique simi- 
lar to the recursive descent LL(1) parsing technique, 
with backtracking to support optional constructions. The 
pattern matcher uses a specification termed a filemap 
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to describe the structure of a file and a record specifica- 
tion to describe the structure of each type of record 
found in the filemap. 

The filemap describes the order of records found in 
the incoming file. The record definition describes the 
structure of each record type. The language borrows 
from COBOL picture clauses for specifying the data type 
of each data element. The structure of the mapfile is 
shown below: 



Using a filemap specification, a system user can 
specify both structure and sequence with minimum am- 
biguity. 

The e-language includes three primitives used in di- 
s viding application documents from an application com- 
munication. The primitive used to split off documents is 
SPLIT <stream, filemap>, which reads the file and proc- 
esses it using the filemap. Additional primitives 
MARK_END, DO_SPLIT and ROUTE_TO_xxx are 
used to do perform functions similar to those provided 
in the EDI de-enveloping procedure. These primitives 
are to be used in the actions associated with records 
matched by the filemap specification. MARK_END 
marks a possible end of a document. DO_SPLIT splits 
out the document identified with the beginning and end 
marks and places a new begin mark immediately follow- 
ing the previous end mark. 

Application documents are separated by selective 
use of these primitives in the filemap. For example, a 
communication file may contain a set of invoice reports. 
These reports are printed a page at a time, but may be 
printed in multiple pages. The filemap specifies how to 
pattern recognize each page and to extract from each 
page the trading partner's identifier. A begin mark is set 
at the beginning of the first page and an end mark set 
at the end of each page. If more than one sequential 
page includes the same invoice identifier, the SPLIT 
continues to pattern match until it reaches a page for 
which the invoice identifier is different, then resets the 
end mark to be at the end of the last page of the group 
of pages with the same invoice identifier. The 
DO_SPLIT primitive is then used to divide out the in- 
voice between the begin and end marks. A sample de- 
enveloping script for application data is shown in FIGS. 
5 A to 5F. 

The script first identifies the filemap specification, 
"invoice" to be used, as shown at 10110. The "record 
[name]" commands, as at 10120, indicate that certain 
commands are to be executed when the named record 
is found in the input data stream. The "printf commands 
shown, as at 10121, print out specified information for 
diagnostic purposes. As shown at 10300 in FIG. 5C, 
each time a record "total3" is found (10310), an end 
mark is set (1 0320). As shown at 1 0400, the script then 
splits the record with the DO_SPLIT command (1 041 0). 
The script then determines at 10420 the receiver, using 
the data element "custnum" shown at 10121 in record 
"terms" at 10120. Then, in line 10430, the script resets 
the start marker. In the following steps, as at 10440, the 
format for each record to be read is defined. 

At 10520 in FIG. 5F, the script directs that each in- 
voice be split, keeping a list of items in the variable "vfl, 
" using the filemap "invoice" and the data from the stand- 
ard input stream "stdin." Finally, at 10600, for each item 
in the list "vfl", the item is routed to the translation work 
center (10640). 

As noted in the preceding script, the de-enveloping 
work center also routes documents to the required des- 
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1. L_MAPFILE - primitive for 'e' mapfile intrinsic 
a. MATCH - high level match given a filemap 

i. MATCH PRIMITIVE - start of the primitive 15 

(1) MATCH RECORD - match the next 
record as specified 

(a) INITBINDINGS - initialize the 20 
connection with data elements 

(b) MATCHSIG NATURE - check if 
the record has the proper signa- 
ture 

25 

(i) PARSESIGNATURE - un- 
derstand the signature speci- 
fication 

(ii) DOMATCHSIGNATURE - 
apply the specification 30 

1) EVALVALEXPR - 
evaluate the predicates 

(c) MATCH FIELD - match the 
specification of the next field ss 

(i) MATCH VALU El S - match 
the user specified field value 

(d) MATCHSTARFIELD - special 
field matcher (varying length) 

(e) EXECUTE BINDINGS - con- 40 
nect data to symbol 

(2) EVALMATCH ACTION - execute 
any action associated with matching 
the record 45 

(3) MATCH FILEMAP - if nested filem- 
aps 

(a) MATCH - recursively match 
(to allow backtracking) 

50 

ii. MATCHOPTIONAL - if the next construc- 
tion is optional 

(1 ) MATCH - recursively match (to al- 
low backtracking) 

iii. MATCHLOOP - if it is a loop 55 

(1 ) MATCH - recursively match (to al- 
low backtracking) 
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tination. The routing function is controlled by a routing 
table. For an EDI document the following document el- 
ements determine how to process the document: a) 
sender, found from the interchange or functional group 
envelope; b) receiver, from the same source; and c) doc- 
ument type, which is from the document envelope. 
Sender and receiver may be known by different names 
from different sources. The system resolves the differ- 
ent aliases into a specific enterprise using an alias table. 
For an application transaction, the following data ele- 
ments determine how to process the transaction: a) 
sender, derived from application interface profiles or 
from document scanning; b) receiver from the same 
source; c) the application transaction, which comes from 
the document. 

The user specifies how to process translation units 
of work by entering in the routing table the following in- 
formation: a) script to be used in the translation; b) the 
destination network or an application transaction; and 
c) sender and receiver. This information is found in the 
routing slip for the work unit. 

Translation Work Center 

The translation work center manipulates an incom- 
ing document into the format that is expected by another 
system. It can convert EDI data to a format that can be 
printed and/or used by applications and can convert a 
file created by an application to a standard EDI format. 
Unlike existing systems ; there is complete flexibility in 
the ability to translate. It can convert from one EDI for- 
mat to another or from one application format to another. 
In the illustrated embodiment, it is implemented as an 
interpreter that understands primitives of the e-lan- 
guage and is used with a script written in the e-language 
to perform transformations on many kinds of data. Al- 
though shown as implemented as an interpreter, imple- 
mentation through use of a compiler is also possible. 

The translation work center is explained in the con- 
text of a sample conversion. A sample input document, 
an invoice, will be converted from the application format 
shown in FIG. 7 to an EDI format, which is an EDI 810 
document, as shown in FIG. 8. A document definition is 
created in the e-language that describes the structure 
of the document and a corresponding bare tree is con- 
structed. Data is read from the input document and 
mapped onto the bare tree. The data is then mapped 
from the populated tree into the EDI 810 document for- 
mat. 

The EDI system manages an EDI data stream with 
an EDI reader and an EDI writer. The purpose of the EDI 
reader is to develop an EDI data tree from an EDI doc- 
ument expression. The e-language provides the capa- 
bility to make a bare tree corresponding to a particular 
document and for creating an EDI tree from a virtual file 
whose body is a document. 

Trees are one type of data variable used in the e- 
language. In turn, data variables are one type of e-lan- 



guage program element. The elements of a program 
written in the e-language are described below. 

Lexical Elements — The e-language recognizes 
a character set that includes alphabetic characters, nu- 

5 merical characters, and special characters. Identifiers 
are names given to variables, functions, subroutines, 
patterns (records), and filemaps in the program. Con- 
stants can be string or numeric constants. Reserved 
words are words with special meanings in the e-lan- 

10 guage that cannot be used for program names or iden- 
tifiers. 

Variables — A variable is a name used to refer to 
objects in the system. The object may be a single ele- 
ment or multiple elements. The three variable types 

15 available in the e-language are arrays, records, and 
trees. Arrays are collections of data values whose indi- 
vidual members are accessed via a numeric index. A 
record is a compound data structure containing multiple 
values, or fields, of various types. 

20 As described in more detail below, trees are com- 
posed of nodes, with an uppermost node called a root 
node (or root). Branches below a node are called the 
node's children or branches. The lowermost or outer- 
most nodes (those with no children) are called leaf 

25 nodes or leaves. 

The e-language provides the capability to make a 
bare tree appropriate for a particular document and to 
create an EDI tree from a virtual file whose body is an 
document. In both cases a pointer to the root of the tree 

30 is created; by assigning pointers, any node of the tree 
can be referenced. 

Expressions/Operators — Expressions are con- 
structs having a well-defined value in the context in 
which they appear. The simplest expressions in the e- 

35 language are identifiers, string constants, function calls, 
array references, and tree (or node) references. Oper- 
ators are characters that designate mathematical or re- 
lational operations. 

Statements — Statements are instructions to the 

40 computer to perform some sequence of operations. The 
types of statements available in the e-language include: 
a) assignment statements; b) conditional statements; c) 
iterative statements; d) IF statements; e) FOR state- 
ments; f) WHILE statements: and g) subroutine calls. 

45 Functions — Functions are collections of instruc- 
tions that return a value. Functions include multi-valued 
functions that return more than one value, subroutine 
definitions, and filemap definitions. Filemaps are func- 
tion-like objects that perform pattern -matching on files. 

50 A filemap accepts as input a list of records and/or other 
filemaps, and matches items in the current virtual file 
with the given records or filemaps. Fields in a record that 
is successfully matched are bound to the items in the 
input file they match. The program can then access the 

55 values of the fields elsewhere. 

Trees are information structures particularly well 
suited to the structure of documents. By representing 
documents as trees, the contents of the documents can 
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be accessed in an expressive and convenient form. The 
tree is like a file buffer, with a definite structure, and in 
the e-language, a variable can be assigned to the tree. 

Every node in an EDI tree can be classified as one 
of the following types. An area consists of a non-empty 
sequence of segment blocks and loop blocks. It can be 
considered as the root of an arbitrary subtree. Its subn- 
odes are segment blocks and loop blocks. A segment 
block represents a block of repeated segments with 
identical segment identifiers. Its subnodes are segment 
bodies. A segment body represents a single segment 
within a segment block. Its subnodes are the elements 
of the segment. A loop block corresponds to one or 
more iterations of a loop. An iteration of a loop is the 
sequence of segment blocks for the segments marked 
as a loop in a standard document. The subnodes of loop 
blocks are loop bodies, analogous to segment blocks 
and segment bodies. A loop body is an iteration of a 
loop; its subnodes are segment blocks. An element has 
the same meaning for an EDI tree as it has for an EDI 
standard - it is the smallest logical portion of a segment. 
Some EDI standards also employs the concept of com- 
posite data elements, which have similar semantics and 
implementation to segments. 

Any node in an EDI tree can be referenced by spec- 
ifying its path. Symbols used in defining EDI documents 
are used to develop the path specification. Three oper- 
ators are used: separator, selector, and arrow operators. 
Separator operators separate nodes in the tree, while 
selector operators select a loop body, segment body, or 
element in that node. An arrow operator points to an 
NTE segment or a subtree of a hierarchical level loop. 
An NTE segment is designated in the X12 standard as 
a floating segment, one that can appear anywhere with- 
in a document. Hierarchical levels, used in some EDI 
documents, show the relationships among different lev- 
els of detail in a shipment, such as pallets on a truck, 
part numbers on the pallet, cartons of a particular part 
number, etc. Such a notation is necessary because an 
NTE is considered an appendage to any segment body 
and an HL subtree is considered an appendix of an HL 
loop. 

An EDI tree is constructed based on a document 
definition. A document definition for an X1 2 81 0 invoice 
transaction set, implemented in the e-language, is 
shown in FIG. 9. The definition is divided into a heading 
area 1100, a detail area 1200, and a summary area 
1300. The heading area includes segments, such as 
segment ST, shown at 1101, and loops, such as 
loop_n1, shown at 1110. The document definition gives 
the "grammar" of an invoice document as agreed to by 
the X12 committee. 

Segments and elements can also be defined as text 
files in the e-language. Two sample segment definitions 
are shown in FIG. 10, expressed in Lisp. These segment 
definitions are for the CUR segment (shown at 2100) 
and for the N1 segment (shown at 2200). Each segment 
definition identifies the name of the segment, such as 



N1 shown at2205, andthetitle, such as "NAME," shown 
at 2210. It specifies a list of document definitions in 
which the segment is used, as shown at 2220. This line 
indicates that the N1 segment is used in the 810 docu- 

5 ment definition (indicated at 2225). 

The segment definition next defines a syntax. The 
syntax definition is used to evaluate a particular seg- 
ment expression to determine whether it complies with 
the standard. This addresses the shortcoming of prior 

10 generation translators in inadequately handling the con- 
ditional notes in segment definitions. For example, seg- 
ment N 1 may have a conditional note that either the sec- 
ond data element must exist or both the third and fourth 
data elements must exist. This note is implemented in 

15 the syntax shown for segment N1 , shown at 2230. The 
conditional is expressed in the statement "((-or 2 (-and 
3 4)))," where the numbers refer to the data elements. 

Next, the segment definition specifies a list of ele- 
ments, as shown at 2240 for the N1 segment. Each el- 

20 ement is indicated as being either mandatory (M), op- 
tional (O), or conditional (C). This ties into the syntax. 
For example, since the syntax provided that either the 
second data element or the fourth and fifth data ele- 
ments must exist, these data elements (element num- 

25 bers 93, 66, and 67) are indicated as conditional. Ele- 
ment 98 is mandatory. 

The position of an element in a segment is used in 
the e-language to refer to the data element. In this ele- 
ment reference notation, the path specified by 

30 "tree\H EADI NG\LOOP_ N1 [3]\N1 [2]" refers to the sec- 
ond element in the N1 segment, which means that ele- 
ment number 93 is being referenced. 

Finally, the segment definition specifies the type 
and version of the EDI standard being used. As shown 

35 at 2250, the N1 segment definition is based on version 
0.0 of the X12 standard. 

The elements themselves can also be defined. Two 
sample data element definitions (also in Lisp) are shown 
in FIG. 11 — element 93 is defined at 3100 and element 

40 98 is defined at 3200. This definition allows the EDI sys- 
tem to verify whether the format of an input data element 
conforms to the data definition. The element definition 
includes the name of the element (e.g., 93, as shown at 
3111), the data type (e.g., alpha-numeric, or AN, as 

45 shown at 3112), the minimum (3113) and maximum 
(3114) length, and the title (e.g., NAME ; as shown in 
3115). Next, the definition specifies the segments in 
which the element is used, as shown at 3120. Finally, 
the type and version of the EDI standard is specified in 

50 3130. 

As shown in the element definition for data element 
98, a list of possible values, shown at 3220, can be in- 
cluded that is used to validate the data element values. 

The e-language can be used to describe the docu- 
55 ment, segment, and element sets that make up EDI 
standards such as X1 2. New document, segment, or el- 
ement types can be defined, or existing definitions can 
be modified. The e-language allows the user to express 
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the description in away resembling the descriptions giv- 
en in the EDI X12 and TDCC Standards books. 

Each element definition includes a specified data 
type, such as the "AN" or alphanumeric data type spec- 
ified for data element 93 at 3112 in FIG. 11 . These data 
types are not hard coded in the e-language, but rather 
their format is defined by a regular expression, which is 
a notation well known in the art. Four sample data type 
definitions are shown in FIGS. 12Ato 12C. The defini- 
tion for a numeric data type with floating decimal is 
shown at 4100, the definition for a floating point decimal 
data type is shown at 4200, the definition for an alpha- 
numeric data type is shown at 4300, and the definition 
for the different classes of data types found in a data 
element definition, and the verification generator asso- 
ciated with the class, is shown at 4400. For example, 
datatypes specified as "n2" will match the definition [nN] 
[0-9] at 4410, so that a pattern will be generated based 
on the X12-n-verification-generator. The verification 
generator accounts for the minimum and maximum 
lengths and scaling factors in developing the pattern. 
The generated pattern is later used to verify that data 
read from an EDI document matches the pattern. 

These regular expressions are evaluated when the 
data element is read or assigned to a tree. This means 
that new data types defined by EDI standard-setting or- 
ganizations can be incorporated into the system with lit- 
tle difficulty. Further, a sufficiently sophisticated user 
could introduce new data types. 

An EDI tree can be constructed based on the doc- 
ument definition using one of two e-language primitives, 
READ EDI (or EDITOTREE) and MAKEDOC. Both 
primitives are based on the document definition as spec- 
ified by its document identifier (such as 810), by the 
standard (such as X1 2), and by the version of the stand- 
ard (such as version 2.2). The EDI system uses a hunt 
sequence associated with the version to resolve the ap- 
propriate segment and element definitions. This is a 
technique that reduces the amount of space required to 
store various versions of the standards. It is a defaulting 
scheme used so that standard specifications that re- 
main unchanged from version to version are stored only 
once. 

The READ EDI primitive reads a data stream ac- 
cording to a specified standard and document definition, 
constructs an EDI data tree structure, and populates the 
tree from the data stream so that it can be accessed 
using the EDI tree path notation. The MAKEDOC prim- 
itive prepares an empty EDI data tree structure based 
on a specified standard and document definition. As ex- 
plained below, this empty tree can later be filled with as- 
signment statements in afilemap structure. MAKEDOC 
creates the minimum bare tree corresponding to the 
specified document definition. However, additional 
nodes or intermediate branches may be needed to con- 
tain the data. When an assignment statement is execut- 
ed, if the required intermediate branch or node does not 
yet exist in the tree, it is created by the assignment. An- 



other primitive, WRITE EDI (or TREETOEDI) writes data 
that has been structured in an EDI data tree structure to 
an output stream in an EDI document format. 

These primitives are implemented in the dynamic 
5 creation of data structures as specified by the stand- 
ards. The document tree contains areas, which contain 
loop blocks or segment blocks, loop blocks in turn con- 
tain loop bodies or segment blocks, segment blocks 
contain segment bodies, and segment bodies contain 
10 data elements. To allow an NTE segment to float, any 
segment body can be given an NTE property. The user 
can refer to and manipulate the contents of the tree by 
using the flexible notation referred to above. A tree can 
have multiple occurrences of loops or segments. In tra- 
15 versing a tree, the specific occurrence required must be 
referred to. For example, in the 81 0 document definition 
shown in FIG. 9, there is a LOOP_N1 1110 defined in 
the HEADING area 1100 that can occur between 1 and 
200 times. Inside the loop is an optional segment N2, 
20 shown at 1111, that can occur up to two times. To refer 
to the second occurrence of the N2 segment in the third 
occurrence of LOOP_N1, the tree path specification 
would be "tree\HEADING\LOOP_N1[3]\N2[2]. M 

These primitives can be used to take data from an 
25 input stream in either EDI or application format and put 
data into an output stream in eitherformat. In the sample 
translation illustrated below, application input data is 
converted to EDI output data. 

The translation of the sample invoice document 
30 shown in FIG. 7 to the EDI 81 0 format shown in FIG. 8 
is implemented with a translation script. The EDI trans- 
lation script used with these two documents is shown in 
FIGS. 13Ato 13F. 

This script illustrates the structure of an e-language 
35 program. A program written in the e-language consists 
of a series of program statements stored in a file with a 
structure similar to a Pascal program. The program can 
begin with array declarations, which can be one-dimen- 
sional or multi-dimensional. None are defined in this ex- 
40 ample. Next is the definitions section, in which functions, 
subroutines, records, and filemaps are defined. The 
function "the_date" is defined at 5110 in FIG. 13A, a 
filemap is defined at 5200 in FIGS. 1 3A to 1 3C, and sev- 
eral records are defined at 5300 in FIGS. 13C to 13F, 
45 with an individual record shown at 531 0. The executable 
commands and statements follow, bounded by a BEGIN 
statement and an END statement, as shown at 5400 in 
FIG. 13F 

The FILEMAP statement, shown at 5200, maps the 
50 input data stream to a set of record assignments. These 
record assignments are listed in nested loops 5210 and 
521 1 . Each record assignment assigns variables to tree 
path specifications. For example, in the "person" record 
assignment 5212, variable "p_name" is assigned to the 
55 tree path 

"tree\HEADI NG\LOOP_N 1 [1 ]\PER[1 ][2]." 

Following the filemap definition is a set of record 
definitions, shown at 5220. These definitions pattern 
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match the data from the input file and assign them to the 
variables that have been assigned to tree paths in the 
record definition statements. In the command section 
5400, a bare tree is created using the MAKEDOC func- 
tion in line 541 0, which specifies that the tree is to be an 
X1 2 81 0 invoice, using version 2.2 of X1 2. The bare tree 
is then populated from the standard input stream, ST- 
DIN, with the pattern -matched data in line 5420 using 
the MAPFILE function. Finally, in line 5430, data from 
the tree is output in EDI X12 format using the TREE- 
TOEDI function, using an "*" as an element separator, 
a "\n" as a segment separator, and an "@" as a subele- 
ment separator. 

The operation of this script is illustrated with the 
sample input shown in FIG. 7 and the sample EDI output 
shown in FIG. 8. In record definition 5310, a search is 
conducted for the string "MAIL" by 5311 and 531 2. This 
is found in the input document at 6110. Having found 
MAIL the blanks following MAIL are skipped by line 
5313. Then, the following fourteen characters of data, 
which in this case will include "Perry Lawrence," are 
read and assigned to the variable p_name in line 531 4. 

Line 5315 then searches for "GROUN." Then, the 
month ("NOV," read by line 5321), day ("27," read by 
line 5323), and year ("1 989," read by line 5325) are read 
and assigned to the variables "mon : " "day," and "year." 
These are concatenated by the function "the-date" de- 
fined at 5100 in FIG. 13A, which in turn was assigned 
to the variable "inv_date" in line 5313. Variable 
"inv_date" in turn is mapped to tree\HEADING\BIG[1 ][1 ] 
in line 5314 (i.e., the first element in the first occurrence 
of the BIG segment). 

Although the ST (transaction set header) and SE 
(transaction set trailer) segments (shown at 1101 and 
1321, respectively, in the document definition shown in 
FIG. 9) are mandatory because they envelope the doc- 
ument, they are not put into the EDI output document at 
this point in the process because they are not yet deter- 
mined. Enveloping segments typically contain control 
information, which cannot be resolved until the transla- 
tion step is completed. For example, the SE segment 
includes the number of segments in the document, 
which is not known until the document is finished. 

As shown at 71 1 1 in FIG. 8, the data is then output 
as "NOV271989" following the BIG segment identifica- 
tion. Similarly line 5327 of FIG. 1 3D reads in the inven- 
tory number, 101903, assigning it to the variable 
"inv_num," which in turn is mapped by line 5315 to 
tree\HEADI NG\BIG[1 ][2], from which it is output at 71 1 2. 
This process is followed to read the remainder of the 
required information from the input document and map 
it to the tree and thence to the output document. 

The inverse of the above operation can also be per- 
formed. An EDI document can be converted into data 
records in a format readable by an application. In such 
a translation, a tree corresponding to the EDI invoice is 
created and populated using the READ EDI primitive. A 
series of assignment statements are used to assign data 



from the tree to fields in data records. When a data 
record is completed, it is output to the application by the 
PUTREC command. A sample of a script for translating 
an EDI document into an application document is shown 
5 in FIGS. 14Ato 14F. 

In the commands in FIGS. 14A to 14D, such as 
"record header" at 13110, the fields for each record of 
data required by the application are defined with picture 
statements. At 13200 in FIG. 14D, the READ EDI prim- 
10 itive is used to read the document "podoc" (purchase 
order document) and create a tree structure populated 
with the data from the EDI document in the input data 
stream. The script next includes a series of assignment 
statements, as at 13310, in which data from nodes of 
15 the tree are assigned to the fields. When the fields in a 
record are filled, the record is output to the output stream 
with the PUTREC command, as at 13400. This process 
continues for each of the records. 

A translation from one EDI format to another EDI 
20 format can be performed as follows. First, READ EDI is 
used to create and populate a first tree corresponding 
to the input document. MAKEDOC is used to create a 
bare second tree corresponding to the desired output 
document. A series of assignment statements are then 
25 used to populate the bare second tree with data from 
the first tree. WRITE EDI then creates an EDI document 
from the populated second tree. 

Similarly, the system can translate a document from 
a first application format to a second application format. 
30 An intermediate tree structure may not be used in this 
case. The document is first pattern recognized. The pat- 
tern recognized data is then assigned to the appropriate 
records for the second document format, and the 
records output to the second application using PU- 
35 TREC. A tree may also be used to represent application 
transactions. 

Enveloping Work Center 

40 Outbound EDI documents are created by the trans- 
lator process. These documents are usually created as 
a result of processing an inbound application transac- 
tion. Although the outbound document contains a com- 
plete address, the facility used for communicating the 
45 document may not be ready. There is therefore a need 
to hold these documents until the communication facility 
is ready. The process of grouping EDI documents into 
a "package" that is to be sent through an EDI commu- 
nication facility is termed "enveloping." 
50 As described above, the EDI enveloping scheme 
employs the concept of an interchange, which is a unit 
of communication from a given sender to a specific re- 
ceiver comprising a package of mail containing multiple 
functional groups. A functional group is a grouping of 
55 EDI documents that correspond to a theoretical organ- 
izational function, such as the purchasing department. 
Each document is a single business document ex- 
pressed in EDI. 
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The system uses a hierarchical file structure to store 
the EDI documents that are ready to be communicated. 
The structure closely follows the EDI enveloping 
scheme. The hierarchy runsfrom communication facility 
as the highest level, to network interface, receiver, send- 
er, functional group, and document. This hierarchical 
structure is also used to store application transactions. 
Outbound application transactions are stored in a simi- 
lar hierarchy, with communication facility at the top ; fol- 
lowed by application interface and application transac- 
tion. 

Thus, a file produced by the translator and its ac- 
companying routing form is moved into a depository 
where the enveloper can find the file when required. The 
translator uses the node, file type (E Dl , non-EDI , or text) 
network or application interface, and other information 
on the routing form to determine where a file should be 
placed. It also consults a table that indicates what sort 
of interchange is used for a given trading partner, func- 
tional group, and node. This file structure, correspond- 
ing to the hierarchy described above, is shown graphi- 
cally in FIG. 6. TP denotes a trading partner, INT inter- 
change method, and FG functional group. In the illus- 
trated embodiment, the file is physically located on the 
fixed disk of the microcomputer on which the system is 
operated. 

When the communication facility is ready it makes 
a request to the enveloper specifying the communica- 
tion facility and eitherthe application interface or the net- 
work interface. A network interface is an interface to an 
EDI transfer or user agent. This means that the packag- 
es communicated through this interface must follow the 
EDI packaging scheme described above. An application 
interface is an application transfer or user agent. This 
means that the packages communicated through this in- 
terface pertains to a more simplified packaging. The pro- 
cedure is to concatenate all transactions and present 
them for transmission. Optionally the transactions may 
also be surrounded by job control language to create a 
job stream to be transmitted to a host. 

When it receives a request from a facility client, the 
enveloper takes files from the directories into which they 
were placed by the depositor. The enveloper locates the 
appropriate directory based on the identity of the node 
and facility being served and the type of file content. 
Files within a given functional group directory are 
wrapped in afunctional group envelope, which is in turn 
wrapped in an interchange envelope. Values for data el- 
ements in the functional group and interchange enve- 
lopes are obtained or generated. When the interchange 
is complete, it is sent to the facility client in the commu- 
nications interface. 

For application data files output by the translation 
work center, the enveloper first batches together the 
documents into a single set for use by the pertinent ap- 
plication. In the illustrated embodiment, the enveloper 
packages the data for the host (attaching job control lan- 
guage, for example) and transmits the packaged data 



through the communications interface to the job entry 
system of the host. In an alternate embodiment where 
the application and the EDI translation system operate 
on the same machine, the documents are grouped into 

5 a single file and placed in a file location agreed to by the 
application and EDI system, and the application is then 
triggered to execute the file. 

Text files are sent directly to the facility client without 
processing. Sender and receiver data are embedded in 

10 application files. This makes the information available 
to the receiver and to the user's enveloping script. 

Claims 

15 

1. A method for translating electronic data in a com- 
puter system (10) from a first format to a second 
format, comprising the steps of: 

20 (a) determining (1) which one of a plurality of 

communication protocols to utilize to receive 
data as a function of a communication process 
used to transmit the data to the computer sys- 
tem (10); 

25 (b) receiving (1) input data in the first format, 

the data comprising a plurality of data compo- 
nents; 

characterized by 

30 

(c) assigning (2) a script name (8110, 8120, 
8210, 8310, 8410, 9120, 9110, 9210) to the re- 
ceived data to identify a de-enveloping proce- 
dure that will be used to separate the plurality 
35 of data components of the received data into 

individual data components, the de-enveloping 
procedure identified being dependent on the 
communication process used to transmit the in- 
put data to the computer system (10); 
40 (d) dividing (2) the received data into individual 

data components by executing the identified 
de-enveloping procedure; 

(e) translating (3) the individual data compo- 
nents from the first format into the second for- 

45 mat which is chosen to be compatible with a de- 

sired destination for the data; and 

(f) arranging (4) the individual data components 
into a package so that the package is available 
for transmission at any time by the computer 

50 system (10) to the desired destination. 

2. The method of claim 1 , wherein said unit of work is 
divided into pages ; said data components comprise 
application data components, and said dividing step 

55 comprises the steps of: 

a. marking a beginning of a data component; 

b. parsing through said unit of work; 
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c. pattern matching data in said pages and ex- 
tracting an identifier from each of said pages; 

d. marking an end of a data component when 
said identifier changes; and 

e. dividing out as a data component the data 
between said marked beginning and end. 

3. The method of claim 1 , wherein said script is de- 
fined in a programming language, said program- 
ming language incorporating a group of translating 
instructions corresponding to several translating 
steps in the flow of translating, including a pattern 
matching procedure for extracting data from a data 
stream, a data tree structure creation procedure, 
and a mapping procedure for mapping extracted da- 
ta to a tree structure and mapping a data tree struc- 
ture to an output stream. 

4. The method of claim 3, wherein said programming 
language uses a relational model to represent data 
to facilitate processing by structured query lan- 
guage commands. 

5. The method of claim 3, wherein said programming 
language is executed through an interpreter. 

6. The method of claim 1 , wherein said translating step 
comprises the steps of: 

a. executing a first script to identify, classify, or- 
ganize, route, and determine the translation re- 
quirements of said plurality of data components 
in said first format; and 

b. executing a second script to transform said 
plurality of data components in said first format 
to said second format. 

7. The method of claim 6, wherein said scripts are ex- 
ecuted by an interpreter. 

8. The method of claim 6, wherein said scripts are ex- 
ecuted by a compiler. 

9. The method of claim 6, wherein said transforming 
step comprises the steps of: 

a. constructing a data tree structure having a 
plurality of branches and a plurality of nodes to 
represent a document or transaction; 

b. mapping one of said plurality of data compo- 
nents in said first format onto said data tree 
structure; 

c. mapping data in said data tree structure into 
said plurality of data components in said sec- 
ond format. 

10. The method of claim 1 , wherein said individual data 
components in said second format are maintained 



in a depository until they are transmitted to said des- 
tination. 

11. The method of claim 9, wherein said data tree struc- 
s ture is defined by specifications of an electronic da- 
ta interchange document standard. 

12. The method of claim 1 1 , wherein said specification 
comprise segment definitions and element defini- 
te tions and wherein said step of constructing a data 

tree structure comprises the steps of: 

a. identifying a specification; 

b. defining a plurality of nodes, said nodes cor- 
15 responding to said segment and element defi- 
nitions; and 

c. developing a path specification for accessing 
said nodes. 

20 13. The method of claim 1 2, wherein said step of iden- 
tifying a specification comprises the steps of: 

a. identifying a specification identifier number; 

b. identifying an EDI standard; 
25 c. identifying an EDI standard version number; 

and 

d. using a hunt sequence associated with said 
version to resolve said segment and element 
definitions. 

30 

14. The method of claim 12, wherein said element def- 
initions have associated datatypes, said datatypes 
being defined by a regular expression, said regular 
expression being computed when said element def- 

35 inition is read. 

15. The method of claim 9, wherein said step of map- 
ping to said data tree comprises the steps of: 

40 a. defining a plurality of data records, each of 

said records having one or more fields: 

b. parsing said one of said plurality of data com- 
ponents; 

c. matching data in said one of said plurality of 
45 data components to said fields in said record 

definitions: and 

d. binding said fields to said matching data. 

16. The method of claim 9, wherein said step of map- 
50 ping from said tree structure comprises the steps of: 

a. determining the identity of delimiters to be 
used to delimit said data; 

b. traversing said data tree in a depth first order; 
55 and 

c. formatting each of said nodes and placing 
said delimiters. 
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17. A system for translating electronic data from a first 
format to a second format, comprising: 

(a) a network; and 

(b) a computer coupled to the network for re- 
ceiving data transmitted from the network; said 
computer including: 

(b1) a communication interface (1) includ- 
ing a driver to accept data in the f i rst format, io 
the data comprising a plurality of data com- 
ponents, and a script (8110, 8120, 8210, 
8310, 8410) which determines a communi- 
cation protocol to utilize to accept the data 
as a function of a communication process 15 
used to transmit the data to the communi- 
cation interface, 

(b2) a de-enveloper (2) coupled to the com- 
munication interface (1 ), said de-enveloper 
(2) including 20 

means for receiving the data from the 
communication interface (1), 
means for assigning a script name 
(8110, 8120, 8210, 8310, 8410, 9120, 25 
9110, 9210) to the received data to 
identify a de-enveloping procedure 
that will be used to separate the re- 
ceived data into individual data com- 
ponents, the identified de-enveloping 30 
procedure being dependent on the 
communication process used to trans- 
mit the data to the communication in- 
terface (1), and 

means for dividing the received data 35 
into individual data components by ex- 
ecuting the identified de-enveloping 
procedure, 

(b3) a translator (3) coupled to the de-en- 40 
veloper (2), said translator (3) manipulating 
the individual data components from the 
first format into the second format which is 
chosen to be compatible with a desired 
destination for the data, and 45 
(b4) an enveloper (4) coupled to the trans- 
lator (3) and the communication interface 
(1), said enveloper (4) grouping the trans- 
lated individual data components into a 
package so that the package is available so 
for transmission at any time by the commu- 
nication interface (1 ) to the desired desti- 
nation. 

18. The system according to claim 17, wherein said 55 
means for assigning a script name further includes: 

means for dividing the received data into indi- 



vidual data components; 
means for identifying sender, receiver and 
transaction type; and 

means for determining the type of transforma- 
s tion needed and destination of the transformed 

individual data components. 



Patentanspruche 

1. Verfahren zum Ubersetzen elektronischer Daten in 
einem Computersystem (10) von einem ersten For- 
mat in ein zweites Format, die folgenden Schritte 
aufweisend: 

(a) Entscheiden (1), welches von einer Anzahl 
von Kommunikationsprotokollen zu verwenden 
ist, urn Daten als eine Funktion eines Kommu- 
nikationsprozesses zu empfangen, der ver- 
wendet wird, urn die Daten an das Computer- 
system (10) zu ubertragen; 

(b) Empfangen (1) von Eingangsdaten in dem 
ersten Format, wobei die Daten eine Anzahl 
von Datenkomponenten aufweisen; 

gekennzeichnet durch 

(c) Zuweisen (2) eines Skriptnamens (8110, 
8120, 8210, 8310, 8410, 9120, 9110, 9210) zu 
den empfangenen Daten, um eine Ent-Umhul- 
lungsprozedur zu identifizieren, die verwendet 
wird, um die Anzahl von Datenkomponenten 
der empfangenen Daten in individuelle Daten- 
komponenten zu separieren, wobei die identi- 
fizierte Ent-Umhullungsprozedur von dem 
KommunikationsprozeB abhangt, der verwen- 
det wird, um die Eingangsdaten an das Com- 
putersystem (10) zu ubertragen; 

(d) Teilen (2) der empfangenen Daten in indivi- 
duelle Datenkomponenten durch Ausfuhren 
der identifizierten Ent-Umhullungsprozedur; 

(e) Ubersetzen (3) der individuellen Datenkom- 
ponenten von einem ersten Format in das zwei- 
te Format, welches gewahlt ist, um mit einer ge- 
wunschten Bestimmung fur die Daten kompa- 
tibel zu sein; und 

(t) Anordnen (4) der individuellen Datenkompo- 
nenten in ein Paket, derart, daB das Paket zur 
Ubertragung zu jeder beliebigen Zeit durch das 
Computersystem (10) an die gewunschte Be- 
stimmung verfugbar ist. 

2. Verfahren gemaB Anspruch 1 , bei welchem die Ar- 
beitseinheit in Seiten aufgeteilt wird, wobei die Da- 
tenkomponenten Anwendungsdatenkomponenten 
aufweisen und wobei der Aufteilungsschritt die fol- 
genden Schritte aufweist: 
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a. Markieren eines Beginns einer Datenkompo- 
nente; 

b. Untergliedern der Arbeitseinheit; 

c. Muster-Gleichheitsuberprufung von Daten 
auf den Seiten und Extrahieren eines Kenn- s 
zeichners von jeder der Seiten; 

d. Markieren eines Endes einer Datenkompo- 
nente ; wenn der Kennzeichner wechselt; und 

e. Herausteilen als eine Datenkomponente der 
Daten zwischen dem markierten Beginn und 10 
Ende. 

3. Verfahren gemaB Anspruch 1, bei welchem das 
Skript in einer Programmiersprache definiert ist, 
wobei die Programmiersprache eine Gruppe von 15 
Ubersetzungsbefehlen beinhaltet, die mehreren 
Ubersetzungsschritten in dem FluB des Uberset- 
zens entsprechen, inklusive einer Muster-Gleich- 
heitsuberprufungsprozedur zum Extrahieren von 
Daten aus einem Datenstrom, einer Datenbaum- 20 
struktur-Erzeugungsprozedur und einer Abbil- 
dungsprozedur zum Abbilden extrahierter Daten in 
eine Baumstruktur und zum Abbilden einer Daten- 
baumstruktur in einen Ausgangsstrom. 

25 

4. Verfahren gemaB Anspruch 3, bei welchem die Pro- 
grammiersprache ein relationales Modell verwen- 
det, urn Daten zu reprasentieren, urn Verarbeitung 
durch strukturierte Abfragesprache-Befehle zu er- 
moglichen. 30 

5. Verfahren gemaB Anspruch 3, bei welchem die Pro- 
grammiersprache durch einen Interpreter ausge- 
fuhrt wird. 

35 

6. Verfahren gemaB Anspruch 1 , bei welchem der 
Ubertragungsschritt die folgenden Schritte auf- 
weist: 

a. Ausf uhren eines ersten Skripts, um die Uber- 40 
tragungserfordernisse der Anzahl von Daten- 
komponenten in dem ersten Format zu identi- 
fizieren, klassifizieren, organisieren ; routen 
und bestimmen; und 

b. Ausfuhren eines zweiten Skripts, um die An- 45 
zahl von Datenkomponenten in dem ersten 
Format in das zweite Format zu transformieren. 

7. Verfahren gemaB Anspruch 6, bei welchem die 
Skripte durch einen Interpreter ausgefuhrt werden. so 

8. Verfahren gemaB Anspruch 6, bei welchem die 
Skripte durch einen Compiler ausgefuhrt werden. 

9. Verfahren gemaB Anspruch 6, bei welchem der 55 
Transformationsschritt die folgenden Schritte auf- 
weist: 



a. Konstruieren einer Datenbaumstruktur mit 
einer Anzahl von Zweigen und einer Anzahl von 
Knoten, um ein Dokument oder eine Transak- 
tion darzustellen; 

b. Abbilden einer von der Anzahl von Daten- 
komponenten in dem ersten Format auf die Da- 
tenbaumstruktur; 

c. Abbilden von Daten in der Datenbaumstruk- 
tur in die Anzahl von Datenkomponenten in 
dem zweiten Format. 

10. Verfahren gemaB Anspruch 1, bei welchem die in- 
dividuellen Datenkomponenten in dem zweiten For- 
mat in einer Ablage gehalten werden, bis sie an das 
Ziel ubertragen werden. 

11. Verfahren gemaB Anspruch 9, bei welchem die Da- 
tenbaumstruktur durch Spezifikationen eines elek- 
tronischen Datenaustausch-Dokumentenstan- 
dards definiert ist. 

12. Verfahren gemaB Anspruch 11, bei welchem die 
Spezifikation Segment-Definitionen und Element- 
Definitionen aufweist und bei welchem der Schritt 
des Konstruierens einer Datenbaumstruktur die fol- 
genden Schritte aufweist: 

a. Identifizieren einer Spezifikation; 

b. Definieren einer Anzahl von Knoten, wobei 
die Knoten den Segment- und den Element- 
Spezifikationen entsprechen; und 

c. Entwickeln einer Pfad-Spezifikation zum Zu- 
greifen auf die Knoten. 

13. Verfahren gemaB Anspruch 12, bei welchem der 
Schritt des Identifizierens einer Spezifikation die fol- 
genden Schritte aufweist: 

a. Identifizieren einer Spezifikations-Kenn- 
zeichnerzahl; 

b. Identifizieren eines EDI-Standards; 

c. Identifizieren einer EDI-Standard-Versions- 
zahl; und 

d. Verwenden einer Suchsequenz, die der Ver- 
sion zugeordnet ist, um die Segment- und Ele- 
ment-Definitionen aufzulosen. 

14. Verfahren gemaB Anspruch 12, bei welchem die 
Element-Definitionen zugeordnete Datentypen auf- 
weisen, wobei die Datentypen durch einen Regel- 
Ausdruck definiert sind, wobei der Regel-Ausdruck 
berechnet wird, wenn die Element-Definition gele- 
sen wird. 

15. Verfahren gemaB Anspruch 9, bei welchem der 
Schritt des Abbildens auf den Datenbaum die fol- 
genden Schritte aufweist: 
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a. Definieren einer Anzahl von Datensatzen, 
wobei jeder der Satze ein oder mehrere Felder 
aufweist; 

b. Untergliedern der einen der Anzahl von Da- 
tenkomponenten; 

c. Gleichheitsuberprufung von Daten in der ei- 
nen der Anzahl von Datenkomponenten mit 
den Feldern in den genannten Satz-Definitio- 
nen; und 

c. Binden der Felderan die Gleichheitsuberpru- 
fungs-Daten. 

16. Verfahren gemaR Anspruch 9, bei welchem der 
Schritt des Abbildens von der Baumstruktur die fol- 
genden Schritte aufweist: 

a. Bestimmen der Identitat von Abgrenzern, die 
verwendet werden ; urn die Daten abzugren- 

zen; 

b. Durchschreiten des Datenbaumes in einer 
In-Die-Tiete-Zuerst-Reihenfolge; und 

c. Formatieren jedes der Knoten und Plazieren 
der Abgrenzer. 

17. System zum Ubersetzen elektronischer Daten von 
einem ersten Format in ein zweites Format, aufwei- 
send: 

(a) ein Netzwerk; und 

(b) einen Computer, der mit dem Netzwerk ge- 
koppelt ist, zum Empfangen von von dem Netz- 
werk ubertragenen Daten, wobei der Computer 
aufweist: 

(b1 ) eine Kommunikations-Schnittstelle (1 ) 
mit einem Treiber, um Daten in dem ersten 
Format zu akzeptieren, wobei die Daten ei- 
ne Anzahl von Datenkomponenten und ein 
Skript (8110, 8120, 821 0 ; 831 0 : 8410) auf- 
weisen, welches das Kommunikationspro- 
tokoll bestimmt, welches zu verwenden ist, 
um die Daten zu akzeptieren, als eine 
Funktion eines Kommunikationsprozes- 
ses, der verwendet wird, um die Daten an 
die Kommunikations-Schnittstelle zu iiber- 
tragen, 

(b2) einen Ent-Umhuller (2), gekoppelt mit 
der Kommunikations-Schnittstelle (1), wo- 
bei der Ent-Umhuller (2) aufweist: 

Mittel zum Empfangen der Daten von 
der Kommunikations-Schnittstelle (1), 
Mittel zum Zuweisen eines Skriptna- 
mens (8110, 8120, 8210, 8310, 8410, 
9120, 9110, 9210) an die empfange- 
nen Daten, um die Ent-Umhullungs- 
prozedurzu identifizieren, die verwen- 
det wird, um die empfangenen Daten 
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in individuelle Datenkomponenten zu 
separieren, wobei die identifizierte 
Ent-Umhullungsprozedur von dem 
KommunikationsprozeG abhangt, der 
verwendet wird, um die Daten an die 
Kommunikations-Schnittstelle (1) zu 
ubertragen, und 

Mittel zum Aufteilen der empfangenen 
Daten in individuelle Datenkomponen- 
ten durch Ausfuhren der identifizierten 
Ent-Umhullungsprozedur, 



(b3) einen Ubersetzer (3) gekoppelt mit 
dem Ent-Umhuller (2), wobei der Uberset- 

15 zer (3) die individuellen Datenkomponen- 

ten von dem ersten Format in das zweite 
Format manipuliert, welches gewahlt wird, 
um mit einer gewunschten Bestimmung fur 
die Daten kompatibel zu sein, und 

20 (b4) einen Ent-Umhuller (4), gekoppelt mit 

dem Ubersetzer (3) und der Kommunikat- 
ions-Schnittstelle (1), wobei der Ent-Um- 
huller (4) die ubertragenen individuellen 
Datenkomponenten in ein Paket gruppiert, 

25 derart, daB das Paket zur Ubertragung zu 

jeder beliebigen Zeit durch die Kommuni- 
kations-Schnittstelle (1) an die gewunsch- 
te Bestimmung verfugbar ist. 

30 18. System gema3 Anspruch 17, bei welchem die Mittel 
zum Zuweisen eines Skriptnamens weiter aufwei- 
sen: 

Mittel zum Aufteilen der empfangenen Daten in 
35 individuelle Datenkomponenten; 

Mittel zum Identifizieren von Sender, Empfan- 

ger und Transaktionstyp; und 

Mittel zum Bestimmen des Typs der benotigten 

Transformation und der Bestimmung der trans- 
40 formierten individuellen Datenkomponenten. 



Revendications 

45 1. Procede pour traduire des donnees electroniques 
dans un systeme d'ordinateur (10) a partir d'un pre- 
mier format en un second format comprenant des 
etapes suivantes: 

50 (a) determiner (1 ) lequel d'une pluralite des pro- 

tocols de communication est a utiliser pour re- 
cevoir des donnees en fonction d'un processus 
de communication utilise pour transmettre les 
donnees au systeme d'ordinateur (10); 

55 (b) recevoir (1 ) des donnees d'entree d'un pre- 

mier format, les donnees comprenant une plu- 
ralite de composantes de donnees; 
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characterise par les etapes suivantes: 

(c) attribuer (2) un norm de scripte (8110, 8120, 
8210, 8310, 8410, 9120, 9110, 9210) aux don- 
nees regues pour identifier une procedure de 
developpement qui sera utilisee pour separer 
la pluralite des composantes de donnees des 
donnes regues en des composantes de don- 
nees individuelles, la procedure de developpe- 
ment identifiee etant dependante du processus 
de communication utilise pour transmettre les 
donnees d'entree au systeme d'ordinateur (1 0); 

(d) diviser (2) les donnees regues en compo- 
santes de donnees individuelles en executant 
la procedure de developpement identifiee; 

(e) traduire (3) les composantes de donnees in- 
dividuelles a partir du premierformat en second 
format qui est choisi pour etre compatible avec 
la destination desiree pour les donnees; et 

(f) arranger (4) les composantes de donnees 
individuelles dans un paquet afin que le paquet 
soit disponible pour la transmission a chaque 
instant par le systeme d'ordinateur (10) a la 
destination desiree. 

2. Le procede de la revendication 1 , dans lequel ladite 
unite de travail est divisee en pages, lesdites com- 
posantes de donnees comprenant des composan- 
tes de donnees d'application, ladite etape de divi- 
sion comprenant les etapes suivantes: 

a. marquer un debut d'une composante de don- 
nees; 

b. analyser ladite unite de travail; 

c. mettre en correspondance des donnees sur 
lesdites pages et extraire un identificateur de 
chacune desdites pages; 

d. marquer une fin d'une composante de don- 
nees quand ledit identificateur change; et 

e. sortir comme une composante de donnees 
les donnees entre ledit debut et ladite fin mar- 
ques. 

3. Le procede de la revendication 1 . dans lequel ledit 
scripte est defini dans un langage de programma- 
tion, ledit langage de programmation incorporant un 
groupe d'instruction de traduction correspondant a 
plusieurs etapes de traduction dans le flux de tra- 
duction, incluant une procedure de mise en corres- 
pondance pour extraire des donnes d'un flux de 
donnees, une procedure de creation d'une arbores- 
cence de donnees, et d'une procedure de represen- 
tation pour representer des donnees extraites en 
une arborescence et pour representer une arbores- 
cence de donnees en un flux de sorti. 

4. Le procede de la revendication 3 ; dans lequel ledit 
langage de programmation utilise un modele rela- 



tionnel pour representer des donnees afin de faci- 
liter le traitement par des commandes de langage 
d'interrogation structures. 

s 5. Le procede de la revendication 3, dans lequel ledit 
langage de programmation est execute par un in- 
terpretateur. 

6. Le procede de la revendication 1 , dans lequel ladite 
10 etape de traduction comprend les etapes suivantes: 

a. executer un premier scripte afin d'identifier, 
classifier, organiser, router et determiner les 
besoins de traduction de ladite pluralite des 

15 composantes de donnees dans le premier for- 

mat: et 

b. executer un second scripte afin de transfor- 
mer ladite pluralite des composantes de don- 
nees dans ledit premierformat en ledit second 

20 format. 

7. Le procede de la revendication 6, dans lequel les- 
dits scriptes sont executes par un interpretateur. 

25 8. Le procede de la revendication 6, dans lequel les- 
dits scriptes sont executes par un compileur. 

9. Le procede de la revendication 6, dans lequel ladite 
etape de transformation comprends les etapes sui- 

30 vantes: 

a. construire une arborescence de donnees 
ayant une pluralite de branches et une pluralite 
de noeuds pour representer un document ou 

35 une transaction; 

b. representer une de ladite pluralite de com- 
posantes de donnees en ledit premier format 
en ladite arborescence de donnees; 

c. representer des donnees dans ladite arbo- 
40 rescence de donnees en ladite pluralite de 

composantes de donnees dans ledit second 
format. 

10. Le procede de la revendication 1, dans lequel les- 
45 dites composantes de donnees individuelles dans 

ledit second format sont maintenues dans un depot 
jusqu'a ce qu'elles soient transmises a ladite desti- 
nation. 

50 11. Le procede de la revendication 9, dans lequel ladite 
arborescence de donnees est definie par des spe- 
cifications d'un standard de documents d'echange 
de donnees electroniques. 

55 12. Le procede de la revendication 11, dans lequel la- 
dite specification comprend des definitions de seg- 
ments et des definitions d'elements et dans lequel 
ladite etape de construction d'une arborescence de 
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donnees comprend les etapes suivantes: 



nant: 



a. identifier une specification; 

b. definir une pluralite de noeuds, lesdits 
noeuds correspondant auxdites definitions de s 
segments et d'elements; et 

c. developper une specification de chemin pour 
acceder auxdits noeuds. 

13. Le procede de la revendication 12, dans lequel la- 10 
dite etape d'identification d'une specification com- 
prend les etapes suivantes: 

a. identifier un numero d'identificateur des spe- 
cification; 15 

b. identifier un standard EDI; 

c. identifier un numero de version d'un standard 
EDI; et 

d. utiliser une sequence de recherche associee 

a ladite version pour dissoudre lesdites defini- 20 
tions de segments et d'elements. 



(a) un reseau; et 

(b) un ordinateur couple aux reseaux pour re- 
cevoirdes donnees transmises du reseau, ledit 
ordinateur comprenant: 

(b1) une interface (1) de communication 
ayant un gestionnaire afin d'accepter des 
donnees dans le premier format, les don- 
nees ayant une pluralite de composantes 
de donnees, et un scripte (8110, 8120, 
8210 ; 8310, 8410) qui determinant le pro- 
tocol de communication a utiliser pour ac- 
cepter les donnees en fonction d'un pro- 
cessus de communication utilise pour 
transmettre les donnees a I'interface de 
communication, 

(b2) un developpeur (2) couple a I'interface 
de communication (1), le developpeur (2) 
ayant 



14. Le procede de la revendication 12, dans lequel les- 
dites definitions d'elements ont des types de don- 
nees associees, lesdits types de donnees etant de- 
finis par une expression de regie, ladite expression 
de regie etant calculee quand ladite definition d'ele- 
ments est lue. 

15. Le procede de la revendication 9, dans lequel ladite 
etape de representation a ladite arborescence de 
donnees comprenant les etapes suivantes: 

a. definir une pluralite d'articles de donnees, 
chacun desdits articles ayant un ou plusieurs 
champs; 

b. analyser ladite une de ladite pluralite de com- 
posantes de donnees; 

c. mettre en correspondance des donnees 
dans ladite une de ladite pluralite de compo- 
santes de donnees avec lesdits champs dans 
lesdites definitions d'articles; et 

d. lier lesdits champs auxdites donnees com- 
parees. 

16. Le procede de la revendication 9, dans lequel ladite 
etape de representer de ladite arborescence com- 
prend les etapes suivantes: 
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a. determiner I'identite de delimiteurs a etre uti- 
lised pour delimiter lesdites donnees; 

b. traverser ledit arbre de donnees dans I'ordre 
"profondeur d'abord"; et 

c. formater chacun desdits noeuds et placer 
lesdits delimiteurs. 55 



moyens pour recevoir les donnees de 
I'interface de communication (1), 
moyens pour assigner un nom de 
scripte (81 1 0, 81 20, 821 0, 831 0, 841 0, 
9120, 9110, 9210) aux donnees re- 
cues afin d'identifier une procedure de 
developpement qui sera utilisee pour 
separer les donnees recues en com- 
posantes de donnees individuelles, la 
procedure de developpement identi- 
fied etant dependant du processus de 
communication utilise pour transmet- 
tre les donnees a I'interface de com- 
munication (1), et 

moyens pour diviser les donnees re- 
cues en composantes de donnees in- 
dividuelles pour executer la procedure 
de developpement identified, 

(b3) un traducteur (3) couple au deve- 
loppeur (2), ledit traducteur (3) manipulant 
les composantes de donnees individuelles 
dudit premier format en le second format 
qui est choisi a etre compatible avec la des- 
tination desiree pour les donnees, et 
(b4) un enveloppeur (4) couple au traduc- 
teur (3) et a I'interface de communication 
(1 ), ledit enveloppeur (4) groupant les com- 
posantes de donnees individuelles tradui- 
tes dans un paquet afin que le paquet soit 
disponible pour transmission a chaque ins- 
tant par I'interface de communication (1) a 
la destination desiree. 



17. Systeme pour traduire des donnees electroniques 
d'un premier format en un second format, compre- 



18. Le systeme de la revendication 17, dans lequel les- 
dits moyens pour assigner un nom de scriptes com- 
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prend en plus: 

des moyens pour diviser les donnees recues 
en composantes de donnees individuelles; 
des moyens pour identifier I'emetteur, le recep- 
teur et le type de transaction; et 
des moyens pour determiner le type de trans- 
formation necessaire et la destination des com- 
posantes de donnees individuelles transfor- 
mees. 
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(defun convmonth (m d y) 
(catch '$retval_convmonth 
(setq mdy (concat m d)) 
(setq mdy (concat md y)) 
(throw *$retval_convmonth mdy))) 

10110 (setq invoice '( 

(loop 
((record header) 
(progn 

(printf "%s" "remit to: ") 

(printf "%x" contact) 

(printf "\n"))) 
((record unused)) 
(setq invdate (convmonth month day year)) 
(progn 

(printf "%s" "date: ") 

(printf "%s" invdate) 

(printf "\n"))) 
((record unused)) 

10120 ((record terms) 

(progn 

(printf "%s" "cust. number:") 

10121 (printf "[%s]" custnum) 
(printf "\n") 

(printf "%s" "terms;") 

(printf "%s" termper) 

(printf "%s" "%") 

(printf "%s" termdays) 

(printf "\n"))) 
((record unused)) 
((record names) 
(progn 

(printf "%s" "bill to:") 

(printf "%s" billname) 

(printf "\n"))) 



FIG. 5A 
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((record streets) 
(progn 

(printf "%s" "street:") 

(printf "%" billstrt) 

(printf "\n"))) 
((record csz) 
(progn 

(printf "%s" "city.state,zip:") 

(printf "%s" billcsz) 

(printf "\n"))) 
((record unused) 
(progn 

(printf "%s" "unsused") 

(printf "\n"))) 
((record unused) 

(setq n 1 )) 
(loop 

((record detail) 

(if (> dozens 0) 
(setq itemun (* dozens units)) 
(setq itemun units)) 
(progn 

(printf "%s" item) 

(printf "%s w dettot) 

(printf "%s" price) 

(printf "%s" units) 

(printf "%s" dozens) 

(printf "\n")))) 
((record unused) 

(progn 

(printf "%s M "unsused") 
(printf "\n"))) 
((record unused) 
(progn 
(printf "%s" "unsused") 
(printf "\n")» 
((record unused) 
(progn 
(printf "%s" "unsused") 
(printf "\n"))) 



FIG. 5B 
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((record total 1) 
(progn 
(printf "%s" merchtot) 
(printf "\n"))) 
((record total2) 
(progn 
(printf "%s" nontot) 
(printf "\n"))) 
10300 10310 ((record total3) 
(progn 
10310 (mark end) 
10400 10410 (setq vf (do_split» 

every time a record of the format total 13 is found set the 
;; ending mark, and split. 

10420 (set app normal receiver vf custnum) 
;; determine the receiver using the data element 

custnum found 
;; in the terms record earlier in the scanning. 
10430 (markstart) 
reset the start marker 

(printf "%s" (-tottot nontot)) 
(printf "\n")) )))) 

10440 (setq header '( 

(filler (x 0) nil) 

(filler (x 4) "MAIL") 

(filler (b 5) nil) 

(contact (x 1 5) nil) 

(filler (x 0 nil) 

(filler (x 9) "INVOICE #") 

(filler (x 1) "\n"))) 

(setq info '( 

(ponum (x 6) nil) 
(filler (x 33) nil) 
(showeth (x 20) nil) 
(month (x 3) nil) 
(filler (b 1) nil) 
(day (x 2) nil) 
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(filler (b 1 ) nil) 
(year (x 4) nil) 
(filler (x 3) nil) 
(invnum (x 0) nil) 
(filler (x 1) M \n"))) 

(setq names '( 

(filler (x 0) nil) 
(filler (x 5) "BILL") 
(billname (x 25) nil) 
(filler (x 0) nil) 
(filler (x 5) "SHIP") 
(shipname (x 9) nil) 
(filler (b 0) nil) 
(filler (x 1) "\n"))) 

(setq detail '( 

(item (x 8) nil) 
(filler (x 14) nil) 
(filler (x 1) " ") 
(filler (x 30) nil) 
(dozens (n "9") nil) 
(filler (b 1 ) nil) 
(units (n "z9") nil) 
(filler (b 7) nil) 
(price (n "z") nil) 
(filler (b 7) nil) 
(detto (n "zz9") nil) 
(filler (x 0) nil) 
(filler (x 1) "\n"))) 

(setq total 1 '( 

(filler (x 0) nil) 

(filler (x 18) "MERCHANDISE TOTAL-") 
(filler (x 7) nil) 
(merchtot (n "zz9") nil) 
(filler (x 1) "\n"))» 
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(setq total2 '( 

(filler (x 0) nil) 

(filler (x 16) "NON-MERCH TOTAL ") 
(filler (x 7) nil) 
(nontot (n "zzz9") nil) 
(filler (x 1) "\n"))) 

(setq total3 '( 

(filler (x 16) nil) 
(duedte (x 1 1) nil) 
(filler (x 0) nil) 

(filler (x 14) "INVOICE TOTAL-") 
(filler (x 7) nil) 
(tottot (n "zz9") nil) 
(filler (x 1) "\n"))) 

(setq streets '( 

(filler (b 0) nil) 
(filler (x 4) "TO ") 
(billstrt (x 17) nil) 
(filler (x 0) nil) 
(filler (x 4) "TO ") 
(shipstrt (x 19) nil) 
(filler (x 0) nil) 
(filler (x 1) "\n"))) 

(setq csz '( 

(filler (b 0) nil) 
(billcsz (x 29) nil) 
(filler (b 0) nil) 
(shipcsz (x 10) nil) 
(filler (x 0) nil) 
(filler (x 1) "\n"))) 

(setq terms '( 

(custnum (x 6) nil) 
(filler (x 55) nil) 
(termper (n "9") nil) 
(filler (x 2) nil) 



FIG. 5E 
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(termdays (x 2) nil) 
(filler (x 0) nil) 
(filler (x 1) "\n"))) 

(setq unused '( 

(filler (x 0) nil) 
(filler (x 1) "\n"))) 

Sets the start marker at the begining of the data stream 

10520 (setq vfl (split stdin invoice)) 

;; Asks that each invoice to split and keep a list in the 
;; variable vfl - the flemap to be used is "invoice" and the 
data to be matched is in "stdin" 

10600 10610 (while vfl 

10620 (setq vf (car vfl)) 

10630 (printf "deenv: routing to translators ") 

10640 (route app to translator vf) 
;; each invoice document is routed to the translator 
work center 

(setq vfl (cdr vfl))) 



FIG. 5F 
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7111 7112 



BIG* 



NOV271989 



101903- 



N1*PE 

N2 * ATHLETIC FASHIONS BILLING 

N3*1445 JONES STREET 

N4 * SAN FRANCISCO*CA*94103 

PER*AD*Perry Lawrence 

N1*SD 

N2*BROADMORE 

N3*1400 WILSHIRE BLVD. 

N4*LOS ANGELES*CA*94800 

IT1*ASTYLE01*60*UN*5 

CTP******SEL*300 

PID*F****G 

TDS*344*02*342 

CTT*1 
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def document doc810: 
area xl2_heading: 

1101 seg ST: m 1 

1102 seg BIG: m 1 
seg NTE: f 100 
seg CUR: o 1 

10 | loop loop_nl: 1 200 

seg Ml: o 1 
1111 seg N2: 0 2 
seg N4 : o 1 
seg REF: o 12 
seg PER: o 3 

endloop 

seg ITD: o 5 
seg DTM: o 1 
seg FOB: o 1 
endarea 

area xl2_detail: 

loop loop_l: 1 99 999 
seg ITI: m 1 
seg NTE: f 100 
seg CUR: o 1 
seg SLN: o 100 
seg J2X: o 10000 
seg IT3: o 1 
seg CTP: o 25 
seg IT4: o 1 
seg ITA: o 10 
seg ITD: o 2 
loop loop_nl_2: 1 ; 
seg Ml: o 1 
seg N2: o 2 
seg N3: o 3 
seg N4: o 1 
seg REF: o 12 
seg PER: o 3 
endloop 
seg DTM: o 10 
seg CAD: o 1 
endloop 
endarea 

area xl2_summary : 
seg TDS: m 1 
seg CAD: o 1 
seg ITA: o 10 
seg ISS: o 2 
seg CTT: m 1 
1321 seg SE: m 1 
endarea 
enddef 

FIGURE 9 



36 



EP 0 553 098 B1 



co 
co co 
o o 

CJ O 



vo cn cm 

H CO O VD 

D CD CN CD 

po co vo vo 

o co cm co 



CO 




ON 

\0 CO 

vo 

o co 
o 

© 

— o 



o 
o 

h co 
Onn 
o o 

o 



oo r> n 
o> co 

o o 

o 

o o ^ 



— * co 
o r- 
co co 
<N O 
O 

o 



O co vo on 



cm in co h 

— H H H (N 

H O 

00 H H H Ol 

U U Vj U U 

o o o o o 

X I I I I I 

10 w w ww w 

+> 10 

£ A A A A A ±> 

>i I I I I I «— t 



co 

O co o 
O O 
*h o 
O O — 



co o 
o I 

CM 
O iH 



m 



in 
o 

CM 
CM 



co 
— * co 
CO o 
ON 

o o 

O w 



CO tfl 
O k 

O > 



o 
o 



IT 
<U 
U) 

VM 

0) 
T3 



O 

o 

CM 
CM 



= I 

w *c 

< tt in 
2 3 CM 

E CM 
CM 

O O 
r-4 CM 
CM CM 
CM CM 



o 



o 



o 



in 
vo 
co 



vo 

CO 



o 

VO 



vo 

in 

CO 

in 
m 

CO 

o 
in 

CO 



co 
o 
co 

CM 

co 

CO 

o 

m 
CO 

_ 

H 
CO 



cm in in in 

H CO O ^ 
CO CO CM CO 

^ CO o ^ 

CO CO CM CO 

CO CM O ^ h 
O CO H fM Tf 
PO CO iH CO ON 

r*- <h ^ co co 
o co on o> in 

CO CO CT> CO CO 

vo o in cm co 

O CO ^ 0> CM 
CO CO on CO CO 

lti o n 

o r** ^ cm co 

CO CO ON ON CO 
VO CO on vo 

o r- r-* cm 

CO CO ON CO 

cm in cm co r-* 
Oh Tf ^ h 

CO CO ON CO ^* 

HOH^tO 
O fM ^ h H 
CO CO ON CO 

o m o on «3- 

ON^fOO 
CO ON CO 

vo ^ in vo o 

H (N O d VO 
rH ^ ON CM PO 



CO 



n o ^ o 

N O rl h 

■^r on cm co 

CM i-H O ON 

CM ON i-» VO 

T CO CN CO 

I s O CO I s 

<-l ON O VO 

CO CO CM CO 



P^ 
VO 

o 
o 



vO 
VO 

o 
o 



co r 

ON O 

o • 

o o 

I 

O CM 
w ,H 
X 

CO 

On ^ 

o 

+j u co o tn 

C O 4J V4 

>i I HS 0) 



T3 
C 

I 



X CM 



o 

PM 
CM 



O O 

m 

CM CM 
CM CM | 



37 



EP 0 553 098 B1 



oo 
co 



o 

CO 



Q 
O 



04 



<<r cm 

H 55 



CO rH 
H VD ^ 
M O — 
r> r 
in 
m • 

U M 

I 

O 
< Eh 



C 

<U > 
CO 



busbsz Voo 

bsssssssss 

s s UQHZOC^Swh 
w = = = = = = = = = 

Q = in 
OZssssssssssD 

OS ssssssssssp 

W S 

Mh3ssssssssssX 
ms uqhso^ojwwnco 

£h = = = = = = = = = = 

25 s ^ 
UUSrssrssrsssS 

ssssssssssH 
X s On 
EhcOssssssssss 

H<£QfM5UHUCD<WOH 
H = UUfcSO040;WW>2 
55 ssssssssss 

W 5 _ H 

= OUfaSOwC^tfc0>io 
— ssssssssssp 



CN S 



<M = 



M < 



a 

CO < 

<n s 
o 
o s 

rH = 

<D 

<u — 
0) 

I 



>4>aCCUfiQUD0)OCU^ 

ssssssssssin 

Q 

ssssssssss 

CDUW JZ^gwpQ 

~ ~ ~ OS 
ssssssssssD 

CQOWMZCUCUQCCOEh 
ssssssssssw 



in 



I 

u 
u 

— Q 
M H 
>h s 



co a; x co 

0QUWH 



PQtfOHOl 
CU CU X CO H 



u 
> 



o o 



J I 



O 



O 
O 
CM 

co 



38 



EP 0 553 098 B1 



«P 

£ 
l 

C 

o 

•H 

w 
to 
<y 
u 

Cu 
X 

0) 

I 

— u 

U (0 
O <H 

a o d> 

•H Q) 

o -h I 

U U -P 

Q) o OJ — 
T3 W tT 1 
^ <t) w 0 

in 

O b 01 

J-> o u 

(O «P 10 

in U — 

0 (a 

c m i 

CP CP 

1 C 
C -H 
O fH 
*H 10 
4J U 
10 W 
U I 

■r-( 0) 

J* 4J 
0) (T3 
> 4J 

id 

C TJ 

A A 
<N »H 
H T3 

x a) 
i 

c «P 
3 a» 



O 0 

«P 

a cu 

•H -H 
}-l U 

0 0 
tn W 

a) a) 
X5 x: 

4J -P 

0) 0) 
iH H 

1 I 

X c 

(T3 -h 

-eg 

. — a i 
O 0) 0) 

>l >i 

*P 4J 

flj <0 

-P -P 

fO 10 

T3 TJ 

I I 

•H -H 

0) 0) 
I I 

QJ Q| 

cp 



A 
O 



I 

O 



-p 

CP 

c 

0) 

rH ^-h 

c — 



<4-i 



•C x: 

<P <P 

&> CP 

c c 

0) V 

rH r— I 

X C 

6 6 



-P 



i <p x: 

— I 4J 
O tP 

A «— » C 

o o <x> 

V — H 
C S — C 

0 O "H 
■h ^ * B 
W H H I 

a cp i = 

X C I T3 

a) o >— c* 

1 rH S 
^ X A 
(0 (0 O 4J 
HgV 

3 s B 
CPH 

0 <0 -P 0 

M 3 <0 

<y a) c 
^ w o 
-H u 

a«H — - 
g *h 
o — 

o 



g 

i 



x: 
-P 
CP 

c 

0) 



X 
(0 



I 



r 

T3 



x: 

■P 
CP 
C 
0) 

fH 

~ X 

& g 

QJ 

u » 



X 
CP 
0) 



0 

-p M 
a 0 

jm a 

cn u 

a> o 

*G to 

— — a) 
cn * — c tj 

O ^-H X3 

— s co tp 

ff\ A O C 
I 10 0*H Q) 
•-I g i <M fH 

— V «H I 

— 0 — ^ X 

= ~= > e 
I I 
0) o 
a a 

>.>i 

<o <o 
-p <p 

A3 (0 

I I 

T3 T3 
0) 0> 
I I 

-P -P 

a) cu 

W 05 



u u 
o o 

«P 4J 

a a 

-r-l -H 
U O 

to cn 

x: x: 
— «p -p 
U o 0* D> 
o c c 
+j ^ a) o 
a o ^ <^ 

u a x c 

O -H (0 -H - 

(A i-t g S 

O O I I 

T3 CO <U O 

^ <u a a* 

0 ^ (0 (0 
4J O -P 4-> 
(0 P (0 <0 

a) <o i i 

C *W "H -H 

0) I *D T3 
CP tJ» 0) 0) 

1 C I I 

0 in a> a> 

•h <o CP CP 

-P o 

(0 (0 

U I A fC 

-h cu «p 

M-i £X CP CP 
-H >, C C 
U P 0) <u 

> -P X c 

1 rd <0 -h 
U T3 g g 

<N -H w 

X 0) 

I * 

C <P P 

0 <P o 

IW IflH 

(J) WW 

T3 



A 
O 

I 

V 



JZ 

-p 

CP 

c 

a> 

X 

10 



<p 

I 

o 



— x: 



0 <T> 
H I 
tfl -^O 
W H ^ 

Q) 

u x: ^* 
ap ^ 
x tp*~- 
0) c ^ 

1 Q) O 

(0 X H 

H <rj v 

3 B i-« 

CP + 

0) fH I 

U (0 ' 
I P A 

a) cro 

h o y 

a 

g <w 

O H 
O — 



= CP 

V c 

w ft) 

+ fH 
r-i C 

CP -H fH * = 
I g S ~ 

O V 

* r 

o *o »*o 
^~#> <p 

AS IS 

o o 

V -P — -P 

r (0 • ro 
g ^ g 

fO o — o 

O 4-1 A <M ^ 

o 







g 




x: 








1 




CP 


H 




c 






a) 












X 


X? 




<0 


4J 




a 


CP 


x: 




c 






a) 


CP 


-p 


•H 


c 


CP 


c 


0) 


c 


«H 


H 


QJ 


g 


c 


fH 




•H 


c 


1 


g = 


•H 


H r 


V 


g 


w v 



< 

CM 

d 

UL 



s TJ" 
CP V <W> 0> 
11*11 
O T? ^TJ O 
<^ CP o¥> ^ 
— -= I r o 
Ci O i — " 
i <P ^— ' 4-> I 
fH (0 • «3 + 
« — i g g k — . i 
M ^ ^ 

— o — o ^ 

A <W A *H A 



O 
O 



O 

o 



39 



EP 0 553 098 B1 



c 



E 
I 



V 

s * 

T3 — 
e¥> CP 
S I 

o 

4-> — 

rd • 

n 

o — 

4h A 



x: 
c 

0) 



x: 
-p 

CP 

c 

rH 

x 



Or* 
C 

o 



eve 

•H w 

e * i 

r-^ rH 

rsi <T\ ^ — 
I 

I o s 

— -^TJ = 

•<*> V 

= CP I * 

T3 I *D " 

<*> rH c*> <P 

5 u- S I 
«— i o 

<0 + (0 • 

6 — B 
Jh — J-i 

o — o — 

«W A <U A 



x: 

«P 

o> 

C 
0) 

X 

E 



CP 

c 

0) 
rH 

c 

£ 

I 



<*> ^ 
I ^ 
T3 — 

A 

«P O 

e v 
o — 

<M A 











o — 










tS3 










1 ^ 




O 0 






CO • 


x: 


«P -P 






as - 


-P 


a a 






i + 


D> 


•H *«H 






»7> * 


C 








W • — ^ 


0) 


o o 


tS3 




1 


i-H 


03 CO 


1 




< - 


X 


o a> 


w 






to 




X 


1 


1 ^ 


X 6 






CO 


CO = 


CP 


o x: x: 






u ^ 


CD CM 


-p -P <P 


^ H 


1 


1 — 


M 


Cli D> CP 


x: i 




•rn > — • 


1 


•H C C 


«p < 


x: h 


-h cr» 


rH v — 


m a) a) 


U* N N 


-p i 


1 i 


o 


U H H 


C 1 1 


tr< 


<c 


-P rH 


CO 1 1 


C 0) w w 


C N 




O* O 


a> x c 


O H ft5 5 


0) 1 




•H «P 




•H X 1 A 1 


rH W 


A 




^■"^ E5 63 


« h O-n 


C 


rH 


O -H 


(0 1 1 


Ifl B H ^ *H 


-H | 


r 


(0 ^ 


0) ^ 4) 0) 


a> i v i 


s g -r-» V 


0) o 


3 o a a 


u x: < * <o 




* 


•o w 


H4J >i>i 


0*-P N mr-, 






o 


(C «5 -P «P 


X t?l 1 - 


Ttj « 




C T3 


> M «3 (T3 


4) C W A A 


A *> • 


A 


O 


0) 4J 4-> 


1 0) >H V o 


V = ^ 


V 


•H JC 


C 10 <0 


JH rH 1 V 




-P 4J 


C © T3 *o 


(0 C *r-\^ s 


^4J A 




(0 CP 


(0 CP 1 1 


rH -H -H ^ 






o c 


rH 1 -H -H 


3 e » 






-H 0) 


A C T3 T3 


<c <0 


u V 






O <U 0) 


0) rH ^ tO 




I 


•H 1 


rH -rH I | 






-H «P -P 


1 3 A V> O s 


Vr 




(Q 0) 0) 


<u cro <*> u <w> 




> e 




H fl) V II ^ 


II 


II 


i i 


W -H w w 


■H (\ # 














•*> 


a a 


o-h jc x: 


s ^ 






>i >i 


rH W <P <P 


0 *H ^ 






-P 4J 


rH 0) 0> CP 


0 w 


• 


• 


(0 <C 


<0 > C C 








«P -P 


i a> a) 




+ 


+ 


« <C 


C C rH rH 


X * 






T3 T3 


0 <0 X C 


cr — 






1 1 


•hi ro *h 


a) w 






•H -H 


w cm g e 








•O T3 


M rH — w 




44 


^3 



0) 0} 

I I 

<D 0) 

(0 (0 



X — 



CO 



C HI 

D -P 

! MH Q) 

J3 0) rH 

Eh — 



I 

o 



l 

o 



CP 

I 

o 













x 




On 




<D 




u 




u 




0 




«p 








•H 








O 




W 




a) 








c 




0 




•H 








«3 




O 




•H 




<4H 




•H 








a> 




> 




— s 1 




^ 0) 




— a 






A 




O 




I 


-p 


V 


rO 




T$ 




1 


1 


-rH 


A 


T3 


V 


0 
1 




-p 




0 




(0 






1 

an 




</> 









m 

d 



o 
o 

m 



40 



EP 0 553 098 B1 











on 














1 














rH 
















1 












» 

w 


rH 


s 












o 


A 
























iTi 
Cn 


n 


i 














V 
















M 










Ui 


/TV 


w 












i 












w 


/»"\ 
w 


<0 




M 
























111 








* — ' 




HI 


<- 




TO 




I I 


r^ 


• 
1 


w 




I, 








w 


>n Lj 

VJ ' M 




fli 

w 














C 




ON 






mm 




a) 




1 






o to 




W 1 




Q 


| 




•H U 




1 




•—J 


rH 


| 






C 




r— i 




o 


<0 c 




o 




CsJ 


o 




U 0) 




-H 




1 




OJ 


-H CP 




-u 




rH 






Mh 1 




<0 






rsj 


r~i 


•H C 




D 






o 


ON 


^ 0 




•H 








1 


0) 




SH 




on 




o 


> <M 




•H 




1 






1 * 








rH 


rH 


r— 1 


C U 




0) 








rH 


» "H 




> 




o 




O 


CM <W 




1 










rH -H 




c 










X ^ 




to 




00 




A 






1 








O 


r > 




04 




in 


r— l 


V 


n I 




H 




m 


ON 


: 


• S i4 




X 




rH 


1 




CM A 1 










o 




1 O <M 














CM 1 i-t 




• 

■» 


s 




r— i 


A 


rH V X 


A 


A 


A 


o 


<N 


O 


X (0 w 


O 


O 


O 




1 




= CO 


i 


i 


1 




rH 






V 


V 


V 








ON A 








• on r> 




*H A JE 



<D I O Q 2 h I — r-^w^o B 
q, o i T3 C4J o — » i 

V i— n— ON I i V <— i 
<P r^r-<^r-^^t-^ | HON— ^ 

■P C M -H <0 TJ I -OH^^ 

*OA A A A A ^(N (N O 
MhOOOOOA I © V 

<D v V v V V O rH — H n: 
TJ s s r r s v • — ^ — *-* 




o 



41 



EP 0 553 098 B1 



0) C 
• flJ 

l« 
o u 

rH -H 
00 (0 

-h a 

0) i"> 



CO <N 



a) 

rH 

•H C 

4H O 
•H 

A3 W 

-P Jh 

« O 

Q > 



T3 
in 
<0 
'D 
C 

<c 

«P 
CO 



T3 

a) 



o 
o 



c 
o 

-p 

•H Q4 
T3 O 

o 

(0 



73 

a> 
o 
-p 
a) 

0) 

u 
-p 



C 
(0 

x: 
u 



M 

O • 

«P * 

bj a 

TJ <U 

c x: 
to a 
s 

a) 

c u 
o c 

(0 

^ rH 

o a 

a> B 

XX o 

u o 

o x: 

W <P 

rH -H 
< 5 



6 



0) 












(0 


e ~ 


a) 




~<P > 


0 


*°. 


-P fl 


•H 


0) 


« u g 


0 


jC 


0 c 


> 


<P 


c 0 c 


c 




0 0 u 


•H 


c 


U II P 




0 


II >h«P 


a 


•H 






p 


c g e n 


6 



C D> 

p Q) 



T3 
C 
0) 



a 
o 

c o 

a) 

rH o> 

•H 0) 



0) 








e 








= ftS 








0 c 






6 K 


< 1 






r s <C (d 


- Qu 






W 0 c C 


II II 






CLi CO || 


r-^ »— I 






s s Xt W 


f-t rsi 


h h in 


g 


II II II ti 




r> m r-» 








in in <n 


c 


rH iH tH f-H 


iH 1-4 


in 


>' 


« 1 1 U— 1 U_ J 




— 0) 




1— 1 r— 1 »—i *— 1 




^ -P H 


c 


H H r( H 


w w 


(0 <C 3 


•H 


' "— 1 


CU (1) 


0) T> C 




rH rH <N CM 


— e 


>i 1 1 




z z z z 


r— 1 r— 1 fQ 


- > > 








>i c c 










w 


H M H M 


hh a 


Tf II II 


•H 




Z Z 






tH rH rH rH 


1 1 - 


C r7(N 




z z z z 




O 




1 1 1 1 


§8- 


g r— 1 r— 1 




CU CU CU CLi 


^•H H 




0000 


iJ »q in 


0) 


P 


0 c 0 0 

J J J J 


1 M 


-POO 


C 


x x 


H H 




1 i 1 1 


-^--^ c 


*0 CQ CO 


0) 


S S X EC 


000 




^ ^ ^ ^ 


2 2 CO 




•H 


a 0 0 a 


M M U 


x: z z 


0 


z z z z 


a o <d 


U M HI 


> 


M M M M 




II O O 


c 


a a a a 


jj w 2 


•H 


w w w w 




<a x x 




SC X X X 


CD O C 










10) Q) 


c 


(U Q> QJ 0) 


^ ^ U 


> Q) 0) 




0 o) <d <u 




c ^ ^ 




u u u 




•H -P «P 


a 


HJ HJ 4J -P 



L. 



c 

o 
w 

M 

0) 

a 

T3 
>H 

o 
o 

0) 

u 

eg 

rH 

in 



< 

CO 

O 

LL 



Jh 
4) 

a) 

TJ 
U 
O 

O 

a> 
u 



a> 
e 
ro 
c 

•0 

u 
o 

u 

<D 



in 



o 
o 



in 



o 
o 

rvi 

in 



42 



EP 0 553 098 B1 



0) o 

e 6 

c c 

12 a 



• • •• 

o o 

P «P 



-H 

.Q w 
s r 

c c 

•H -H 

a a 



(0 



II 



I 

(fl 
II 



Q) H Q) 
>iP >i«P 

p to a-p <o a 

•H P -H -H JJ -H 
U til N O W N 

II II II II II II 



rH rH H f\] H H H 

rH »-» H H rH rH iH iH 

n n T3 T3 *r *r 

J^l ~~~~~~ 




< < ja tn 

W W r r 

^---p «p 

<U 0) c c 
Q) 0) -H -H 
M ^ M ^ 

<p v a a 



»h 

73 
T3 

Jh 
O 

o 
<u 

>h 



Q Q Q 
< < < 
WWW 

X S3 X 



a a a 

w £5 &§ 
x a x 



0) <d Q) q) qj Q) 



■P 

c 

3 



CM 



C N 
C fl) o 

0) jC 
A -P 
4-> II 
O 

O <M 
A O 

A 

«P 

c c 

N 

O <u 
73 



6 
o 
c 



CO 

c 

0> 
N 

o 

T3 



*4H 

o 

b' 

c 



0) o 



>1 

-P 
W 
II 



Q) = i— l 

•H W -P 

in CO o 

a = 4J 

ii H ii 



Q) 
O 

•H 

a 



h oi n ^ \o h 



H H H H 0< & 
M M H M U U 



c c c c c c 



H H Eh H h* 

M M M M M M 

a a a a a a 
o 



0) 



c 

3 



C 




O 
H 

c 



lilt 
a a a a a a 

I M M M M M M 
<<<<<< 

W W W W S W 

a a a a a a 



= g 

W -H 

s 73 
II 11 

iH in 



a q 

M M 

a- a 



33 

w w 
I i 
a a 
o o 

ss 



CD 
Li. 



a o 



c c 



M M 

I I 

a a 
o o 

S3 

o'q 1 



0) 0) 0) 0) 0) 0) 


iH 


m 


(0 


-P 


0) 0) 0) 0) 0) 0) 


M rH 


M Jm| H U >H ^ 


11 <w 


rH 


rH 


O 


^ b ^ b ^ M 


< < 




C -H 


0) 


0) 


P 


.p -P -P -P -P -P 
















W W 




• • 










Q Q 
















•P 


4> W 










oT <D 


id 


(A 6 










0) 0) 


0 


3 0) 










V4 U 


o 


C -P 










-P -P 


rH 


3 -H 












T3 


73 73 












U 


U U 












o 


o a o 












o 


o o u 












0) 


0) O 0) 




iH 










Jn| rH u 




rH 









ID 



43 



EP 0 553 098 B1 



0) u 

nog 

-P 0*H 
W O T3 



O 

10) i"H 
6 O <d 
D -h «p 
c u o 



(A 



0} 



HOE 10 <0 
>iH g g-H4J 
-P O-H O U 0 

w ut3 c a JJ 

S S S 5 S S 



4J-P«P«P<P4J«Pr* 
CCCCCCC + 

•H -H -H -H -H -H H C 
Jh U U U U U U II 

aaaaaac^c 



P 

H O 
(«HHH 4J 

.p « « | 

O -P -P «P > 
4J O O O C 
|«p -P -p *H 
C III* 

0 > C M = 
C C O 0) 

•H C E 

1 ii ii ii w 

•P i— i»-if-i 10 
OHHH4J 

-P — — — o 

I CO CO CO 4-> 

* a a a 

<D &■» H E-» <D 
E ^ ^ ^ O 

X >4 > H 

11 i 1 i ° 

<P ^^^V 
|0> 0) 0) c 
> Q) 0) 03 -H 

c u u u u 









mns 


a 




0 




o 




H 


0 




o 


C 




a) 


U 



ID 



O 
r-l 

C 



t3 
C 
0} 



CM 

in 



o 
o 

CM 

in 



CM 



in in 



in 



n 

in in in 



CO 



0) 

H 

> 



a) 
a 

H 

> 



O 

CO 

d 

u. 



c 
o 

u 

a 



* * h -it in 
xx!q X X X 
u o o o o o 

-H -H -H -H H -H 
CX p4 a O. Oi Oi 



U U U 0) u u 

<u o) a) n o) o> 

HHH flj H H 

T3 HHH C H H 
14 C «H H -H fH H 

O H <w w (u Q«Mh <u 
O CP T3 
0) 0) C 



u 
o 

<0 
Q> 
A 

T3 

O 

o 



CO 

in 



o 
o 
m 
in 



44 



EP 0 553 098 B1 



0) 

a 

(0 

> 



r- 

CM 

r> 

in in 

r-l m <n 

cn cn m 

m fn in — % * 

in in * w 

4a —4a —ja * JT * 

a a cu o a 

u o -h e 

m -h m -h m a u p 

o a a) a 4) o c 

«H <H H ^ H | 

rH C f-H >*rH <G r-l > 

O *H <T3 *H 0) -H C 

g <4-| *C »H >, «W -H 



•H 



CP 
0) 

xi 





















lj 
























H 


o 




o 




"c 


H 






a 


H 










P 






cn 


r 


















W 










W 






u 


•H 








w 


•H 






•H 


Q) 




-H 




•H 


a> 






0) 


0 




Q> 




0) 










i— 1 




3 






• — i 
















i— I 


A3 








> 








id 


> 






> 






> 




> 




in 








in ^ 








in 






in o\ 








* 






















X^ 


x 4a 


x^ >T 


x^ 


*x4a 






X 



u u u u u o 

•H »H -H *H »H -H 

CU Qu C3u CU fii fiU 



C 



(0 ^4 m a> m u a> 

c a) a) e a) a) e 

HH flHH (0 

13 HH fiHH fi 
U C -H -H H -H | 

O «H «W <M i3 <M »M W 

u T3 
0)O c 

u xi a) 



q a u u u u u 

»H «H # H »H -H »H «H 

CU CU CU QU CU QU di 



0) 0) T3 fl) 0) T3 Q) 

i-H rH *Q i-l f-4 *0 r-l 

T3 H r-l (flHH <C H 

W C-H-H hH-W M 

o -H in iw j3 tu m(u 

<1><D c 

14 XI <U 



o 
o 

m 
in 



45 



EP 0 553 098 B1 




4J 

o 
o 



*T 2 * fs* in * fH * rvj * in* 
ouoouuoooooooo 

•H »H »W «H -H *H *H -r-l -H *H *H -H «H »H 

aaaaaaaaaaaaaa 



U U U U U tH U u u 

rH a) a)Q)a) o) h a> o) o) 0) o> 

«-H >i^H 4-> *H *H >*rH 4J rH ^ »H 

XJ H+JH «3rH a-H^^-j (OH 

Jm| C *H -H -H 4-> -H -H -H -H -H 4-> -H -H -H -H 

O -H <W O <H O tW N <W U 4-1 10 <W N *W <W 
U CP 

a) a) 



c 
a) 







^ ^ in 






* — * ^* n 






^ a) ' m ^ n 


X X 




X X w 


T3 O U 




0 u oxuouo 


0) *H -H 


(0 






E 


a-H a-H a 0 a a a a 


3 


0) 


a a -h 


C Jm b 


4J 


^ u u a to u 


3 0) 0) 


•H 


0>0)0)JmO 0) C 0) 






HHH O H gH O rH 4-> 


•O HH 


T3 


i-t >HHH g H N H *H 




U 


C -H 4-> -H O -H -H -H O *H C 


O *H <M <M 


OH^H W 4-1 O *w *D <H T3 *w 3 




0 


CP 


a> 0) 


a) 


0) 







o 
o 
n 
in 



46 



EP 0 553 098 B1 



0) 

rH 

> 



* 

If 
u 
a 
u 

0) 



o o o 

•H *H *H 

a a a 

0) 0) 0) 
O HH 
•H HH 
M -H -H 



I 

0) 



I 

< 

Eh 

o 

w 
cn 



a 
w 
£ 
s 

03 



rH 

> 



i 

< 

o 

X 

o 

w 
s: 

i 

i 

s 

W 



0) 
D 

rH 

> 



c 

s 

CO 



rH 

> 



N 

* fH * * iH * « 

O O O O O O 00 
^4 ^4 ,-4 ^4 ^4 ^4 

0* CL Cu ft CL Q* Ou Qu CX 
MJhJhOJhIhJhOUJh 

H HH |#H iH *H |rH rH 



JmI C -H -H -H Q) -H -H -H O -H -H 
O H <M <M ^ g <W <H <W C<M<H 

T3 O 'O 

c o) a) c 

<D rH .Q 0) 



fN 

o 
o 

fN 

o 
o 



s 

o 



o 
o 

>! 

10 

g 
II 
a) 
a) 
c in 

•H 
D> 

0) O 
XI «H 



ii 

C 

8 

<D 
0) 

a 

CO 



s 

II 

C 

a 
e 

CP 
0) 
0] 



— 4-> 
0) C 

o <u 

O 0) 

> rH 

c a) 

-H 

- a) 
c <u 

*H >H 
AJ 

CO -H 

rH 

•H Q) 
<4H 4J 

a-H 

(0 Jh 

o o c 

fM n O 

in in | 

o 
o 



in 



47 



EP 0 553 098 B1 



1 311 0 record header 
begin 

ehcusn pic x(5) 
ehedpo pic x(15) 
ehtrid pic x(9) 
ehedlk pic x(9) 
ehdppo pic x(10) 
eh name pic x(30) 
ehaddl pic x(30) 
ehadd2 pic x(30) 
ehcity pic x(20) 
ehstcd pic x(2) 
ehzip pic x(9) 
ehcnty pic x(16) 
ehedct pic x(15) 
ehedph pic x(15) 
ehcarn pic x(15) 
ehcust pic x(5) 
ehtord pic x(3) 
ehedpf pic x(2) 
eheddt pic x(4) 
ehedtm pic x(3) 
eherfd pic x(70) 
ehdcmd pic x(1) 
ehord picx(4) 
ehlmdt pic x(4) 
ehtyme pic x(4) 

end 



record note 
begin 

eicusn pic x(5) 
eiedpo pic x(15) 
eitrid pic x(9) 
eintqf pic x(3) 
eispis pic x(2) 



FIG. 14A 
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eispin pic x(50) 
eiorrf pic x(4) 
eilmdt pic x(4) 
eityme pic x(4) 

end 



record detail 
begin 

edcusn pic x(5) 
ededpo pic x(15) 
edtrid pic x(9) 
edord pic x(4) 
edlmdt pic x(4) 
edtyme pic x(4) 

end 



record detain 
begin 

elcusn pic x(5) 
eledpo pic x(15) 
eltrid pic x(9) 
ellisq pic x(2) 
elitnb pic x(15) 
elorqt pic x(4) 
elorqu pic x(2) 
eledpr pic x(5 
eledpm pic x(2) 
elsprf pic x(10) 
eiitds pic x(25) 
eirqdt pic x(4) 
eicspt pic x(15) 
elcarn pic x(15) 
elcsri pic x(3) 
elitcg pic x(2) 
eldivn pic x(4) 
elorrf pic x(6) 



FIG. 14B 
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elprcd pic x(4) 
ellmdt pic x(4) 
eltyme pic x(4) 

record detsln 
begin 

escusn pic x(5) 
esedpo pic x(1 5) 
estrid pic x(9) 
eslisq pic x(2) 
esstsq pic x(2) 
esstqt pic x(4) 
esstqu pic x(2) 
esqfOI pic x(2) 
esfdd pic x(30) 
esqf02 pic x(2) 
esfd02 pic x(30) 
esqf03 pic x(4) 
esfd03 pic x(4) 
esord pic x(4) 
eslmdt pic x(4) 
estyme pic x(4) 

end 

record detmea 

emcusn pic x(5) 
emedpo pic x(15) 
emtrid pic x(9) 
emlisq pic x(2) 
emmsrf pic x(2) 
emdmqf pic x(3) 
emdimu pic x(2) 
emdimd pic x(6) 
emdimf pic x(5) 
emstsq pic x(2) 
emspis pic x(4) 



FIG. 14C 
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emord pic x(4) 
emlmdt pic x(4) 
emtyme pic x(4) 

end 

record detnte 
begin 

eccusn pic x(5) 
ecedpo pic x(15) 
ectrid pic x(9) 
eclisq pic x(2) 
ecspis pic x(2) 
ecntqf pic x(3) 
ecspin pic x(50) 
ecord pic x(4) 
eclmdt pic x(4) 
ectyme pic x(4) 

end 
begin 

13200 read edi podoc 

'Building first header record 

HEAr = PODOC\HEADINGd 
13310 ehedpo=head\beg[1][3] 
ehdppo= head\ref [1 ] [2] 
ehedct = head\per [1 ] [2] 
ehedph = head\per [1 ] [4] 
ehcarn = head\td5[1 ] [5] 
NAM = PODOC\HEADING\N1 LOOP[1 ] 
ehname= NAM\N1 [1 ] [2] 
ehcusn=NAM\N1 [1][4] 
ehadd1=NAM\n3[1][1] 
ehadd2=NAM\n3[1][2] 
ehcity=NAM\n4[1][1] 
ehstcd = NAM\n4[1][2] 
ehzip=NAM\n4[1][3] 
ehcnty=NAM\n4[1][4] 

FIG. 14D 
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ehcust = podoc\heading\n1 loop[2]\m [1 ] [4] 
putrec header 

Building second header for note segment 

eiedpo=head\beg[1][3] 

eicusn=head\n1loop[1]\n1 [1][4] 
putrec note 

'Building first detail record 

FOREACH P1 IN PODOC\DETAIL\D_LOOP DO 

begin 

ededpo = head\beg [1 ] [3] 

edcusn = head\n1 loop [1 ]\n1 [1 ] [4] 

'Building second detail record 

eiedpo = head\beg[1 ] [3] 

elcusn = head\n1 loop[1 ]\n1 [1 ] [4] 

p1 =podoc\detail\d_loop[n] 

ellisq = p1\po1[1][1] 

elorqt=p1\po1 [1][2] 

elorqu = p1 \po1 [1 ] [3] 

elitnb=p1\po1[1][7] 

eiitds=p1\po1[1][9] 

elcspt=p1\po1 [1][11] 

eledpr=p1\ctp[1][3] 

eledpm = p1 \ctp [1 ] [5] 

elsprf=p1\ref[1][2] 

elrqdt=p1\dtm[1][2] 

elcarn=p1\td5[1][5] 

'Building third detail record, mea segment 

FOR EACH S1 IN P1\SLN DO 

begin 

esedpo = podoc\heading\beg [1 ] [3] 

escusn = podoc\heading\n1 loop[1 ]\n1 [1 ] [4] 
eslisq=S1[1] 
esstsq=S1[2] 



FIG. 14E 
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esstqt=S1[4] 
esstqu=S1[5] 
esqf01=S1[9] 
esfd01=S1 [10] 
esqf02 = S1 [11] 
esfd02 = S1 [12] 
esqf03=S1 [13] 
esfd03=S1 [14] 
end 

'Building fourth detail record 
FOR EACH M1 IN P1\MEA DO 
begin 

emedpo= podoc\heading\beg[1 ] [3] 

emcusn = podoc\heading\n1 loop[1 ]\n1 [1 ] [4] 
emlisq=p1\po1[1][1] 
emmsrf=M1 [1] 
emdmqf = M1 [2] 
emdimu = M1 [4] 
emdimd=M1[5] 
emdimf=M1[6] 
end 

'Building fifth detail record 
begin 

ecedpo = podoc\heading\beg [1 ] [3] 
eccusn- podoc\heading\n1 loop[1]\n1 [1 ] [4] 
eclisq=p1\po1[1][1] 
end 
end 
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